Bug#985267: desktop-base: leaves alternatives after purge: /usr/share/desktop-base/active-theme -> /etc/alternatives/desktop-theme

[Aurélien COUDERC <coucouf@debian.org>]

Le lundi 15 mars 2021, 10:26:10 CET Andreas Beckmann a écrit :

> Hi,

Dear Andreas,

> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8:

Thanks for testing and reporting this.
This was an issue due to the addition of a new option for the alternative for 
the bullseye theme, and not correctly removing the one from the previous theme 
on prerm.
It’s fixed in git and will be uploaded shortly.

Still some general questions below about alternatives management.

[…]

> While there is ongoing discussion how to remove alternatives correctly
> (see https://bugs.debian.org/71621 for details) the following strategy
> should work for regular cases:
> * 'postinst configure' always installs the alternative

We also do it on 'postinst abort-upgrade' and 'postinst abort-remove', is it 
something that we shouldn’t do ?

> * 'prerm remove' removes the alternative

We also do it on 'prerm deconfigure', I understand from your explanation below 
that we shouldn’t ?

> * 'postrm remove' and 'postrm disappear' remove the alternative

We don’t do that currently and have a lot of different alternatives set up. 
Should we really duplicate the removal code into postrm in addition to prerm ?

> In all other cases a maintainer script is invoked (e.g. upgrade,
> deconfigure) the alternatives are not modified to preserve user
> configuration.
> Removing the alternative in 'prerm remove' avoids having a dangling link
> once the actual file gets removed, but 'prerm remove' is not called in
> all cases (e.g. unpacked but not configured packages or disappearing
> packages) so the postrm must remove the alternative again
> (update-alternatives gracefully handles removal of non-existing
> alternatives).


Thanks,
--
Aurélien