Bug#71621: Policy on update-alternatives still needed
Guillem Jover <guillem@debian.org> writes:
> A deconfigure happens for three reasons, Configure + Depends (other
> package removal), Breaks and M-A:same instances syncing.
> That's the only problematic and tricky maintainer script case I see,
> because due to the way dpkg and apt (or other frontends) interact,
> deconfigure becomes a quite normal occurrence during upgrades, which
> means that if we remove alternatives on deconfigure we are bound to lose
> manually set state. But not removing them means we could end up with a
> non-working active alternatives for an unspecified period of time while
> upgrading, but then this is also “normal” for several other parts for
> most packages during an upgrade, and the correct solution to that is to
> successfully finish the upgrade.
> So I like Jonathan's exposition of the cases, and I also think the
> correct answer here is to not remove them on deconfigure, because
> supposedly we want to preserve the package, and I don't think the
> possible flip-flop effect of changing alternatives is desirable.
Ah, indeed. Good point. In the normal Breaks case when this isn't just
temporary, it will be followed by a package removal as apt removes the
broken package, which will of course then remove the alternative. So this
isn't ideal, but in the Breaks case where it's the most likely that the
package won't keep working, it will all clean itself up.
> But at the same time alternatives are problematic because they are not
> tied to any specific package (they are like virtual files), so if a
> package would depend on an alternative being functional during an
> upgrade we might need to guarantee that they are always non-broken
> through something like a new u-a command to temporarily stage that
> specific alternative, which would get automatically reactivated on
> reinstallation during package configure. Although I'm finding it
> difficult to think about any alternative being used like that, the
> closest one is awk but the dependencies for those are pretty minimal.
It feels to me like we don't have the tools to properly solve this yet (so
Policy needs to be written without an eye to such facilities), but that
the better long-term solution would be to have a way to declare
alternatives so that dpkg handles them directly rather than through
maintainer scripts, in which case there are further options open, such as
dpkg remembering the manual alternative configuration and restoring it
once the deconfigured package has been reconfigured. (I suspect this is
oversimplified.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: