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

Bug#71621: marked as done (Standardize when update-alternatives --remove may be called)

Your message dated Fri, 11 Aug 2017 12:44:51 -0700
with message-id <87o9rlx51o.fsf@iris.silentflame.com>
and subject line Closing inactive Policy bugs
has caused the Debian Bug report #71621,
regarding Standardize when update-alternatives --remove may be called
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
71621: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71621
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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]

--- End Message ---
--- Begin Message --- 
control: user debian-policy@packages.debian.org
control: usertag -1 +obsolete
control: tag -1 +wontfix

Russ Allbery and I did a round of in-person bug triage at DebConf17 and
we are closing this bug as inactive.

The reasons for closing fall into the following categories, from most
frequent to least frequent:

- issue is appropriate for Policy, there is a consensus on how to fix
  the problem, but preparing the patch is very time-consuming and no-one
  has volunteered to do it, and we do not judge the issue to be
  important enough to keep an open bug around;

- issue is appropriate for Policy but there does not yet exist a
  consensus on what should change, and no recent discussion.  A fresh
  discussion might allow us to reach consensus, and the messages in the
  old bug are unlikely to help very much; or

- issue is not appropriate for Policy.

If you feel this bug is still relevant and want to restart the
discussion, you can re-open the bug.  However, please consider instead
opening a new bug with a message that summarises and condenses the
previous discussion, updates the report for the current state of Debian,
and makes clear exactly what you think should change.

A lot of these old bugs have long side tangents and numerous messages,
and that old discussion is not necessarily helpful for figuring out what
Debian Policy should say today.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: