[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#71621: Policy on update-alternatives still needed



On Sun, 2012-09-23 at 10:03:29 -0700, Russ Allbery wrote:
> In prerm:
> 
> if [ "$1" = "remove" ] || [ "$1" = "deconfigure" ] ; then
>     update-alternatives --remove tf /usr/bin/tf5
> fi
> 
> is correct I think.  The possible invocations of prerm are:
> 
> prerm remove
> old-prerm upgrade new-version
> conflictor's-prerm remove in-favour package new-version
> deconfigured's-prerm deconfigure in-favour package-being-installed version
>   [removing conflicting-package version]
> new-prerm failed-upgrade old-version
> 
> We do want to remove the alternative for all the remove cases, and we
> don't for the upgrade case.

Certainly.

> The deconfigure case is used with Breaks, where we would want to remove
> the alternative (since the package is broken).

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.

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.

> That leaves failed-upgrade, where we're either about to do an
> upgrade (and hence will call postinst again and would just recreate the
> alternative) or we're about to call abort-upgrade in postinst.
> 
> As near as I can tell, postinst should just unconditionally call
> update-alternatives; it's at worse a no-op.

Yes.

regards,
guillem


Reply to: