Bug#71621: No policy on calling update-alternatives (was Re: update-alternatives)

[cjw44@flatline.org.uk (Colin Watson)]

Package: packaging-manual
Version: 3.2.1.0

peter karlsson <peter@softwolves.pp.se> wrote:
>How do I get update-alternatives to keep information when upgrading a
>package?
>
>Currently I have postinst add it and prerm remove it, but if I set the
>alternative to point to something else than the default, this means
>that that information gets lost everytime I upgrade the package...

(This is a long, rambling answer to a short question. Sorry.)

You need to remove the alternative only in certain conditions.

On my system, there are no less than eight distinct ways used by
packages to remove alternatives (excluding special-case conditions like
that used by ae, and folding down the various ways used to express
conditions on $1):

  1. prerm, remove
     (communicator-smotif-475, elvis-tiny, eterm, exuberant-ctags,
     iamerican, ibritish, less, miscfiles, perl-5.005-base, rxvt,
     util-linux)
  2. prerm, remove|upgrade
     (xterm)
  3. prerm, remove|upgrade|deconfigure
     (icewm-gnome, icewm, ipchains, ipfwadm, perl-5.005,
     perl-5.005-debug, perl-5.005-suid, perl-5.005-thread, w3m, w3m-ssl)
  4. prerm, remove|failed-upgrade|deconfigure
     (ae, bison, csh, ee, elvis, emacs20, fte, ftp, fvwm, gcc, gom,
     gom-x, gpc, g++, guile1.3, info, irssi-gtk, irssi-text, itcl3.0,
     itcl3.1, itk3.1, jdk1.1, jdk1.1-dev, joe, libopenldap1, lukemftp,
     mawk, mpg123, nano, ncftp2, pinfo, procps, psptools, rsh-client,
     talk, tcl8.0, tcl8.2, tcl8.2-dev, tcl8.3, tcl8.3-dev, tclx8.0.4,
     tcsh, telnet-ssl, tix41, tk8.0, tk8.2, tk8.3, twm, vim-gtk,
     wu-ftpd, xbase-clients, xboard, xcoral, ytalk)
  5. prerm, remove|deconfigure
     (lesstif-bin, ssh-askpass, ssh, zsh, zsh30
  6. prerm, unconditionally
     (expect5.24, expect5.31, expectk5.24, ircii, man-db, pgp-i, pgp-us,
     sawfish, tetex-bin, wenglish, wfrench, wmaker, wngerman, xcal,
     xcolorsel, xcontrib, xless, xrn, xvncviewer, xvt)

  7. postrm, remove|failed-upgrade|deconfigure
     (gawk)
  8. postrm, unconditionally
     (freeciv-xaw3d, libqt2-dev, powershell)

Note also that dh_installxaw generates unconditional uses of
update-alternatives in prerms, affecting some of the packages above.
This package list won't be complete, as it's just what I happened to
have installed here.

It's clear that there is no consensus about what to use, and there is no
guidance either in the packaging manual (Section 10 would seem to be the
logical place) or in the update-alternatives(8) man page. I think
Section 10 of the packaging manual ought to clarify this.

It's probably worth trying to analyse the cases in maintainer scripts to
see where they break, on the understanding that a package should not
remove and reinstall its alternative(s) on a simple upgrade, as that
breaks manually set alternatives with our current dpkg as described by
Peter above. I realize this is a bug in dpkg - it's inconsistent with
the behaviour described in the man page - but it's still biting a lot of
people, and there's no need to remove the alternative on a simple
upgrade anyway unless it's being changed.

The following cases result in alternatives being removed that might
shortly afterwards be reinstalled:

  prerm upgrade
  prerm failed-upgrade
  postrm upgrade
  postrm failed-upgrade
  postrm abort-install
  postrm abort-upgrade

Also, removing alternatives in 'postrm abort-upgrade' might mean that
you don't get them back unless 'postinst abort-upgrade' reinstalls them,
and removing alternatives in 'postrm purge' is always redundant if
you've already removed them in either 'prerm remove' or 'postrm remove'.

This leaves prerm remove, prerm deconfigure, postrm remove, and postrm
disappear. [fx: sweats] You only need to call update-alternatives in one
or the other remove case, and I'm not sure about the remaining two
cases.

Could we please have some guidance about this in the packaging manual?
Every time I try to work this out I get a different answer. At least if
all packages do it the same way then any future bugs in
update-alternatives might manifest themselves consistently rather than
in several different and hard-to-predict ways.

Thanks,

-- 
Colin Watson                                     [cjw44@flatline.org.uk]