Debian Bug report logs - #582873
dpkg-maintscript-helper: please provide helper for setting up alternatives

version graph

Package: dpkg; Maintainer for dpkg is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg is src:dpkg.

Reported by: Colin Watson <cjwatson@debian.org>

Date: Wed, 13 Sep 2000 23:18:01 UTC

Severity: wishlist

Found in version dpkg/1.15.7.2

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, debian-mentors@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#71621; Package packaging-manual. Full text and rfc822 format available.

Acknowledgement sent to cjw44@flatline.org.uk (Colin Watson):
New Bug report received and forwarded. Copy sent to debian-mentors@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: cjw44@flatline.org.uk (Colin Watson)
To: submit@bugs.debian.org
Subject: No policy on calling update-alternatives (was Re: update-alternatives)
Date: Thu, 14 Sep 2000 00:16:32 +0100
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]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#71621; Package packaging-manual. Full text and rfc822 format available.

Acknowledgement sent to Brian May <bam@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 71621@bugs.debian.org (full text, mbox):

From: Brian May <bam@debian.org>
To: cjw44@flatline.org.uk (Colin Watson)
Cc: 71621@bugs.debian.org
Subject: Re: Bug#71621: No policy on calling update-alternatives (was Re: update-alternatives)
Date: 14 Sep 2000 17:01:32 +1100
>>>>> "Colin" == Colin Watson <cjw44@flatline.org.uk> writes:

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

I had a proposal to replace these scripts with XML format. However, I
haven't got much feedback yet... 

I think the benefit of my proposal to this particular problem would be
that it allows the system administrator to setup the method used by
all packages, rather then each individual package maintainer. eg some
administrators may want to force the higher priority task to take
precedence, where as others may want to preserve the currently
installed value.

See http://snoopy.apana.org.au/~bam/debian/ for details of my
proposal.

PS: I will be away next week, so may be delayed in responding.
-- 
Brian May <bam@debian.org>



Bug reassigned from package `packaging-manual' to `debian-policy'. Request was from Colin Watson <cjwatson@flatline.org.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `wishlist'. Request was from Colin Watson <cjwatson@flatline.org.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 71621 112828. Request was from Colin Watson <cjwatson@flatline.org.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Disconnected #71621 from all other report(s). Request was from Colin Watson <cjwatson@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Bug closed, send any further explanations to cjw44@flatline.org.uk (Colin Watson) Request was from Colin Watson <cjwatson@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reopened, originator set to Colin Watson <cjwatson@debian.org>. Request was from Colin Watson <cjwatson@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 71621 112828. Request was from Colin Watson <cjwatson@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to Manoj Srivastava <srivasta@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Colin Watson <cjwatson@debian.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #29 received at 112828-close@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: 112828-close@bugs.debian.org
Subject: Bug#112828: fixed in debian-policy 3.5.7.0
Date: Sat, 31 Aug 2002 06:34:35 -0400
We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive:

debian-policy_3.5.7.0.dsc
  to pool/main/d/debian-policy/debian-policy_3.5.7.0.dsc
debian-policy_3.5.7.0.tar.gz
  to pool/main/d/debian-policy/debian-policy_3.5.7.0.tar.gz
debian-policy_3.5.7.0_all.deb
  to pool/main/d/debian-policy/debian-policy_3.5.7.0_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 112828@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Manoj Srivastava <srivasta@debian.org> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 31 Aug 2002 02:18:02 -0500
Source: debian-policy
Binary: debian-policy
Architecture: source all
Version: 3.5.7.0
Distribution: unstable
Urgency: low
Maintainer: Debian Policy List <debian-policy@lists.debian.org>
Changed-By: Manoj Srivastava <srivasta@debian.org>
Description: 
 debian-policy - Debian Policy Manual and related documents
Closes: 47298 69311 81852 97755 100346 100472 106280 106826 109672 111025 112828 113525 114949 116134 118608 131441 134977 137521 137521 138681 139067 139820 139832 139969 140697 141307 141903 143770 144297 144411 145067 146703 146756 147554 150456 151328 152965 153704 154142 154660 155680 156546 157131
Changes: 
 debian-policy (3.5.7.0) unstable; urgency=low
 .
   * Fixed some broken hrefs in links
   * No longer use local debiandoc stuff (it's been fixed upstream)
   * Added table of contents (index.html) to policy-process.sgml, fixing
     the new error reported to bug #137521                    closes: Bug#137521
   * Fixed a couple of typos                                  closes: Bug#139832
   * Ran through the policy document looking for long instances of text in
     the <tt> tag, and changed it to <file> where appropriate. This is
     since the <file> tag can handle line breaking, but the <t> flag does
     not.                                                     closes: Bug#139820
   * Change the requirement to ask permission to make devices to merely
     requiring a notification.                                closes: Bug#106280
   * Added a build dependson docbook utils.                   closes: Bug#154660
   * Since this is being built with a newer version of debiandoc-sgml, this
     should display better with lynx.                         closes: Bug#153704
   * Add in the crypto-in-main amendment.          closes: Bug#81852, Bug#144411
   * we no longer have task packages, instead, we define tasks using a
     special field in the control file (and these should be added only
     after discussion on the mailing lists)                    closes: Bug#97755
   * Clarify wording in the section for packages providing fonts.
                                                              closes: Bug#109672
   * Fix the doc base file for policy process     closes: Bug#137521, Bug#147554
                                                              closes: Bug#146756
   * using set -e is not dubious advice. Rejecting this.      closes: Bug#139969
   * Make the directory one is building under ./debian/ be up to the
     maintainer, instead of mandating ./debian/tmp/           closes: Bug#144297
   * Add a standards version                                  closes: Bug#145067
   * Added virtual package debconf-2.0                        closes: Bug#151328
   * Added The Window Manager Specification Project support to the default
     window manager selection mechanism                       closes: Bug#155680
   * The confusion between /var/mail and /var/spool/mail seems to have been
     disambiguated.                                           closes: Bug#114949
   * Mention the new Build-Depend-Indep semantic and the new
     build-indep/build-arch rules in upgrading checklist      closes: Bug#116134
   * Made package naming rules in policy consistent. I did not eliminate
     the duplication, since I don't want to make major changes to the flow,
     since we are supposed to be re-writing policy anyway.    closes: Bug#131441
   * Clarified wording about cases where we may have concrete and virtual
     packages with the same name.                             closes: Bug#134977
   * Fixed typo 'be be'                                       closes: Bug#138681
   * Fixed typo in appendix G -- example of diversion         closes: Bug#140697
   * fix typo shlib: -> shlibs:                               closes: Bug#141903
   * Provide a link between two sections dealing with virtual packages.
                                                              closes: Bug#143770
   * Fixed xtifr's email address in the menu policy           closes: Bug#152965
   * Allow shared library names to be have a hyphen between library name
     and soversion if the library name ends in a number.      closes: Bug#100472
   * Permit some libraries to only install static libs.       closes: Bug#100346
   * Remove the debug option, add noopt           closes: Bug#157131, Bug#113525
   * provide dhcp-client virtual package.                     closes: Bug#154142
   * We do not need bits in policy that ``should not be enforced''.
                                                              closes: Bug#150456
   * We are building this with the latest debianndoc-sgml.    closes: Bug#146703
   * Finish incorporating all of the accepted changes in Bug#72335, and
     this                                         closes: Bug#141307, Bug#156546
   * Added virtual package aspell-dictionary                  closes: Bug#139067
   * Added virtual package radius-server                      closes: Bug#118608
   * Clarifying manual pages is not a policy issue.           closes: Bug#112828
   * Corrected the ldconfig handling instructions.            closes: Bug#111025
   * Not a policy issue.                                      closes: Bug#106826
   * Removed the /usr/doc/ symlink clause.          closes: Bug#47298, Bug#69311
Files: 
 f0da89116b92e54347d2924dcb891bc3 792 doc optional debian-policy_3.5.7.0.dsc
 538deca6636d771319afea1405dcc196 569509 doc optional debian-policy_3.5.7.0.tar.gz
 13c3dd1a4cad18ecb08d13f7605ca9d6 595702 doc optional debian-policy_3.5.7.0_all.deb
 fc34e5d47979c1fe6bbbfae067bc25e5 93119 byhand - policy.txt.gz
 12f50e6fdbfeda37e11a4588c172b351 2137 byhand - menu-policy.txt.gz
 56b51697d5f7924c4c6f95b7e75386fb 1563 byhand - mime-policy.txt.gz
 4f02b12bef47d46284be9aedabae845a 4497 byhand - policy-process.txt.gz
 d5b675249edb9396659d5ef8c427f9dc 4400 byhand - perl-policy.txt.gz
 e84ca799d0bd503879c7332ce7010037 104301 byhand - policy.html.tar.gz
 745262ba198b4cd35549768b400ad054 2804 byhand - menu-policy.html.tar.gz
 6c9855fc81bbd236d964b00fff6b50db 2163 byhand - mime-policy.html.tar.gz
 1936adb9629913a178c5977101073df8 5200 byhand - policy-process.html.tar.gz
 ad20fd4399f0cf475919d2c47bac9f69 5804 byhand - perl-policy.html.tar.gz
 57bfae059e907807da5ca6978bef12f3 6104 byhand - debconf_specification.txt.gz
 2b6ac31aefc3ed74bad716b3fb2eb60f 30171 byhand - debconf_specification.html
 3ed7aa5a489834b24bb28ff377a34aa9 10982 byhand - libc6-migration.txt
 754f5c28f50298c94d96ee39aa3a0026 9170 byhand - virtual-package-names-list.txt
 445f783dd5d3d56e23c32974889f7d69 175739 byhand - policy.ps.gz
 7a4d94570f1cb1f7f99c68e42fef5bdf 411899 byhand - policy.pdf.gz
 540f308e7fac7ec81f2c065f6a0aabc3 17344 byhand - upgrading-checklist.txt
 93679f707ec4cbc94b6f667afb1f2600 34997 byhand - fhs-2.1.html.tar.gz
 4beb6c43e8a0845e619e798b5516d217 103024 byhand - fhs.txt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9cIM+Ibrau78kQkwRAme5AJ9p2Nvn8QcNjtGt/Z31fFm6qkxEUgCgr4Ch
iAYeNJy71t9IdQ1nMkoXnlU=
=NMk/
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org:
Bug#71621; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org. Full text and rfc822 format available.

Message #34 received at 71621@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: 71621@bugs.debian.org
Subject: Re: Bug#71621 acknowledged by developer (Bug#112828: fixed in debian-policy 3.5.7.0)
Date: Sat, 31 Aug 2002 12:04:36 +0100
On Sat, Aug 31, 2002 at 05:48:20AM -0500, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #71621: No policy on calling update-alternatives (was Re: update-alternatives),
> which was filed against the debian-policy package.
[...]
>    * Clarifying manual pages is not a policy issue.           closes: Bug#112828

(#71621 and #112828 were merged.)

I think #71621 is an interoperability and consistency issue, and thus
suitable for policy. For instance, packages that remove and reinstall
alternatives on upgrade (at least used to) break local configuration in
the form of manually set alternatives, and I believe using
update-alternatives in this way could cause alternatives to be sensitive
to upgrade ordering when multiple packages providing the same
alternative are upgraded in the same run. This feels like exactly the
kind of thing that policy ought to mention.

If it is nevertheless determined that this bug is suitable for a best
practices document of some kind rather than the policy manual then I'd
appreciate it if it could be left open in a holding area somewhere so
that I don't have to file it again if and when the new document omits
it.

Thanks,

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



Bug unarchived. Request was from Colin Watson <cjwatson@debian.org> to control@bugs.debian.org. (Wed, 12 Mar 2008 07:51:56 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#71621; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #41 received at 71621@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: 71621@bugs.debian.org
Subject: Policy on update-alternatives still needed
Date: Wed, 12 Mar 2008 10:00:14 +0000
reopen 71621
thanks

I recently ran into this yet again, with a set of packages (scim et al)
calling update-alternatives --remove in 'prerm upgrade', and thereby
breaking user configuration on every upgrade. I do not think that the
issue has got significantly better in the 7.5 years since I originally
reported this bug.

Manoj closed this bug in 2002 with the comment "Clarifying manual pages
is not a policy issue". As I said in response to that at the time:

  I think #71621 is an interoperability and consistency issue, and thus
  suitable for policy. For instance, packages that remove and reinstall
  alternatives on upgrade (at least used to) break local configuration
  in the form of manually set alternatives, and I believe using
  update-alternatives in this way could cause alternatives to be
  sensitive to upgrade ordering when multiple packages providing the
  same alternative are upgraded in the same run. This feels like exactly
  the kind of thing that policy ought to mention.

Policy documents other matters that consist of instructions on how to
use system tools in ways that produce interoperable packages. For
example, 8.1.1 "ldconfig", 8.6.2 "How to use dpkg-shlibdeps and the
shlibs files", 9.2.2 "UID and GID classes" (adduser --system), and 9.3.3
"Interfacing with the initscript system" (update-rc.d). I do not see how
update-alternatives is materially different from these.

I'm not asking for policy to duplicate the manual pages. The manual
pages tell you how to use the tools to perform specific actions, as they
should. I'm asking for something at a higher level: policy should
recommend standards for the actions that should be performed using these
tools in order to produce packages that form a well-integrated, coherent
system. This should not be news: policy already does this in other
cases, so I simply want update-alternatives to be added to the family.

The reason I care is that this is clearly a matter of great confusion. I
don't think it's a matter of strong technical disagreement as such,
otherwise I realise that the policy list probably wouldn't be the right
place to bring it up; I think it's simply a matter where there is little
guidance for developers and so it's easy for people to create subtle
bugs, much as they probably would do if e.g. there were no guidance on
the proper use of update-rc.d.


Based on the analysis I did back in 2000, which I think is still largely
sound, I think that policy should recommend that 'update-alternatives
--remove' must not be called in any of prerm upgrade, prerm
failed-upgrade, postrm upgrade, postrm failed-upgrade, postrm
abort-install, or postrm abort-upgrade, because these cases cause an
alternative to be removed that may shortly afterwards be reinstalled,
which can make update-alternatives erroneously switch the alternative
from manual to auto mode. Typically, a package should call
'update-alternatives --remove' in either prerm remove or postrm remove.
However, in my original analysis I was unsure about the prerm
deconfigure and postrm disappear cases; I would appreciate other
contributions here.

To go along with this, the result would be more readable and useful if
the correct process for installing an alternative were also documented,
although this is not something that people get wrong nearly so often.

Please reconsider this bug.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]




Bug reopened, originator not changed. Request was from Colin Watson <cjwatson@debian.org> to control@bugs.debian.org. (Wed, 12 Mar 2008 10:03:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#71621; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #48 received at 71621@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Colin Watson <cjwatson@debian.org>, 71621@bugs.debian.org
Subject: Re: Bug#71621: Policy on update-alternatives still needed
Date: Sat, 15 Mar 2008 17:25:56 +0000
Colin Watson writes ("Bug#71621: Policy on update-alternatives still needed"):
> Based on the analysis I did back in 2000, which I think is still largely
> sound, I think that policy should recommend that 'update-alternatives
> --remove' must not be called in any of prerm upgrade, prerm
> failed-upgrade, postrm upgrade, postrm failed-upgrade, postrm
> abort-install, or postrm abort-upgrade, because these cases cause an
> alternative to be removed that may shortly afterwards be reinstalled,
> which can make update-alternatives erroneously switch the alternative
> from  manual to auto mode.

Another way to look at this is as a bug in update-alternatives.

Generally we arrange things so that maintainer scripts should not look
at $1 except in special circumstances.  This eliminates many large
classes of potential bug.  It would seem preferable to arrange that
this be the case for u-a too.

We could make update-alternatives
 * retain and use the manual setting of the link by a not-currently
   provided alternative, ie make the alternative be ENOENT
   when the user's manual selection goes away (temporarily or
   permanently)
 * retain the manual configuration but simply not use it when
   then user's manual selection is unavailable.

Of these I prefer the former.  Is there some reason not to ?

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#71621; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #53 received at 71621@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>, 71621@bugs.debian.org
Subject: Re: Bug#71621: Policy on update-alternatives still needed
Date: Sun, 16 Mar 2008 01:47:16 -0700
On Sat, Mar 15, 2008 at 05:25:56PM +0000, Ian Jackson wrote:
> Colin Watson writes ("Bug#71621: Policy on update-alternatives still needed"):
> > Based on the analysis I did back in 2000, which I think is still largely
> > sound, I think that policy should recommend that 'update-alternatives
> > --remove' must not be called in any of prerm upgrade, prerm
> > failed-upgrade, postrm upgrade, postrm failed-upgrade, postrm
> > abort-install, or postrm abort-upgrade, because these cases cause an
> > alternative to be removed that may shortly afterwards be reinstalled,
> > which can make update-alternatives erroneously switch the alternative
> > from  manual to auto mode.

> Another way to look at this is as a bug in update-alternatives.

> Generally we arrange things so that maintainer scripts should not look
> at $1 except in special circumstances.  This eliminates many large
> classes of potential bug.  It would seem preferable to arrange that
> this be the case for u-a too.

> We could make update-alternatives
>  * retain and use the manual setting of the link by a not-currently
>    provided alternative, ie make the alternative be ENOENT
>    when the user's manual selection goes away (temporarily or
>    permanently)

It seems to me that this would just be trading one bug for another.  Having
an alternative that was manually set remain pointed indefinitely at a
missing file after package removal, until the user notices and resets it,
doesn't sound like a desirable user experience to me.

>  * retain the manual configuration but simply not use it when
>    then user's manual selection is unavailable.

That sounds more promising to me.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org




Changed Bug title to `Standardize when update-alternatives --remove may be called' from `No policy on calling update-alternatives (was Re: update-alternatives)'. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 17 Mar 2008 06:15:14 GMT) Full text and rfc822 format available.

Disconnected #112828 from all other report(s). Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 17 Mar 2008 06:15:15 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#71621; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #62 received at 71621@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: 71621@bugs.debian.org
Subject: Re: Bug#71621: Policy on update-alternatives still needed
Date: Tue, 18 Mar 2008 18:41:30 +0000
Steve Langasek writes ("Re: Bug#71621: Policy on update-alternatives still needed"):
> On Sat, Mar 15, 2008 at 05:25:56PM +0000, Ian Jackson wrote:
> >  * retain the manual configuration but simply not use it when
> >    then user's manual selection is unavailable.
> 
> That sounds more promising to me.

If we do this and retain the existing maintainer scripts then
everything will be fine *except* that while (say) nvi is unpacked but
not configured, the system will mysteriously use vim (say) instead.

Perhaps more thought is actually needed.  I really don't like the idea
of asking maintainers to switch on $1.  That always goes wrong.  But
we could ask them to pass their $1 to u-a ?

Also, if the package is unpacked because it was just upgraded, and you
then say --remove, the prerm isn't run.  So just checking $1 in the
prerm isn't sufficient.  It has to be done in the postrm (as well, if
not only).

That means that while the package is being removed, it will inevitably
sometimes leave a broken alternative.

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#71621; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #67 received at 71621@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 71621@bugs.debian.org
Cc: debhelper@packages.debian.org
Subject: Re: Bug#71621: Policy on update-alternatives still needed
Date: Wed, 19 Mar 2008 09:04:04 +0100
On Tue, 18 Mar 2008, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#71621: Policy on update-alternatives still needed"):
> > On Sat, Mar 15, 2008 at 05:25:56PM +0000, Ian Jackson wrote:
> > >  * retain the manual configuration but simply not use it when
> > >    then user's manual selection is unavailable.
> > 
> > That sounds more promising to me.
> 
> If we do this and retain the existing maintainer scripts then
> everything will be fine *except* that while (say) nvi is unpacked but
> not configured, the system will mysteriously use vim (say) instead.

It's still way better than having no editor.

> Perhaps more thought is actually needed.  I really don't like the idea
> of asking maintainers to switch on $1.  That always goes wrong.  But
> we could ask them to pass their $1 to u-a ?

debhelper postinst snippets tend to check $1 for most operation, I don't
see a big problem in mandating their usage.

Another solution is to define the alternatives in some debhelper
configuration file (debian/package.alternatives) and let debhelper create
the right postrm/postint snippet.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Bug 71621 cloned as bug 582873. Request was from Jakub Wilk <jwilk@debian.org> to control@bugs.debian.org. (Mon, 24 May 2010 10:18:05 GMT) Full text and rfc822 format available.

Bug reassigned from package 'debian-policy' to 'dpkg'. Request was from Jakub Wilk <jwilk@debian.org> to control@bugs.debian.org. (Mon, 24 May 2010 10:18:07 GMT) Full text and rfc822 format available.

Bug Marked as found in versions dpkg/1.15.7.2. Request was from Jakub Wilk <jwilk@debian.org> to control@bugs.debian.org. (Mon, 24 May 2010 10:18:07 GMT) Full text and rfc822 format available.

Changed Bug title to 'dpkg-maintscript-helper: please provide helper for setting up alternatives' from 'Standardize when update-alternatives --remove may be called' Request was from Jakub Wilk <jwilk@debian.org> to control@bugs.debian.org. (Mon, 24 May 2010 10:18:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#582873; Package dpkg. (Wed, 02 Mar 2011 09:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 02 Mar 2011 09:15:03 GMT) Full text and rfc822 format available.

Message #80 received at 582873@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 71621-submitter@bugs.debian.org, 582873@bugs.debian.org, Jakub Wilk <jwilk@debian.org>, Brian May <brian@microcomaustralia.com.au>
Subject: Re: Policy on update-alternatives still needed
Date: Wed, 2 Mar 2011 03:10:45 -0600
Hi Ian,

Ian Jackson wrote:
>> On Sat, Mar 15, 2008 at 05:25:56PM +0000, Ian Jackson wrote:

>>>  * retain the manual configuration but simply not use it when
>>>    then user's manual selection is unavailable.
[...]
> If we do this and retain the existing maintainer scripts then
> everything will be fine *except* that while (say) nvi is unpacked but
> not configured, the system will mysteriously use vim (say) instead.
>
> Perhaps more thought is actually needed.  I really don't like the idea
> of asking maintainers to switch on $1.  That always goes wrong.  But
> we could ask them to pass their $1 to u-a ?
>
> Also, if the package is unpacked because it was just upgraded, and you
> then say --remove, the prerm isn't run.  So just checking $1 in the
> prerm isn't sufficient.  It has to be done in the postrm (as well, if
> not only).

I would like to revive this thread, because I think you were right
about in an ideal world not needing to check $1 in maintainer scripts.  

The first question: what should the behavior be?

I. If the user does not express a preference.

If the user has not explicitly chosen an alternative, it might seem
that there is nothing to worry about.  Just use the highest-priority
alternative that is configured at any given moment.  But that is not
quite right, because:

 - sometimes no alternative is configured;
 - a command like "editor" toggling during each upgrade between
   different interfaces would be unpleasant.

What we actually want is the highest-priority alternative that is
usable, which is to say, the highest-priority alternative that was
completely configured at some point and was not removed since then.
Meaning:

 * when the package is configured, register the alternative;
 * when the package is removed, unregister the alternative.

Following this line of logic,

 - preinst would never install an alternative;
 - postinst would always install an alternative;
 - prerm remove would remove an alternative, but
   prerm upgrade and prerm deconfigure would leave well enough alone;
 - postrm remove and disappear would remove an alternative, but
   postrm upgrade would leave well enough alone.

> That means that while the package is being removed, it will inevitably
> sometimes leave a broken alternative.

Won't prerm remove take care of it?

Hints welcome, as always.
Jonathan




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 25 09:11:46 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.