Debian Bug report logs - #71621
Standardize when update-alternatives --remove may be called

Toggle useless messages

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

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]

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

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>

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

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-----

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

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]

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

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]

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

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.

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

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

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

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.

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

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/

Message #72 received at 71621-submitter@bugs.debian.org (full text, mbox, reply):

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

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

From: Jakub Wilk <jwilk@debian.org>

To: 71621@bugs.debian.org

Subject: Re: Bug#71621: Policy on update-alternatives still needed

Date: Thu, 20 Sep 2012 17:00:27 +0200

* Colin Watson <cjwatson@debian.org>, 2008-03-12, 10:00:
>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.

I didn't get better in 12 years either!

I've just tested 665 packages that use update-alternatives.
122 of them removed an alternative on upgrade.

-- 
Jakub Wilk

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: 71621@bugs.debian.org

Cc: Jakub Wilk <jwilk@debian.org>

Subject: Re: Bug#71621: Policy on update-alternatives still needed

Date: Thu, 20 Sep 2012 18:50:11 +0200

On Thu, Sep 20, 2012 at 05:00:27PM +0200, Jakub Wilk wrote:
> * Colin Watson <cjwatson@debian.org>, 2008-03-12, 10:00:
> >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.
> 
> I didn't get better in 12 years either!
> 
> I've just tested 665 packages that use update-alternatives.
> 122 of them removed an alternative on upgrade.

Could you report bugs ?
Maybe this test should be included in piuparts.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

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

From: Jakub Wilk <jwilk@debian.org>

To: 71621@bugs.debian.org

Subject: Re: Bug#71621: Policy on update-alternatives still needed

Date: Sun, 23 Sep 2012 13:29:39 +0200

* Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 2012-09-20, 18:50:
>>I've just tested 665 packages that use update-alternatives.
>>122 of them removed an alternative on upgrade.
>
>Could you report bugs ?

I don't think we should be filing bugs before there's consensus _how_ 
exactly to fix them.

But I'll post list of affected packages and a dd-list to debian-devel.

-- 
Jakub Wilk

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

From: Russ Allbery <rra@debian.org>

To: 71621@bugs.debian.org

Subject: Re: Bug#71621: Policy on update-alternatives still needed

Date: Sun, 23 Sep 2012 10:03:29 -0700

Jakub Wilk <jwilk@debian.org> writes:

> I don't think we should be filing bugs before there's consensus _how_
> exactly to fix them.

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.  The deconfigure case is used with Breaks,
where we would want to remove the alternative (since the package is
broken).  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.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

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

From: Guillem Jover <guillem@debian.org>

To: 71621@bugs.debian.org

Subject: Re: Bug#71621: Policy on update-alternatives still needed

Date: Sun, 23 Sep 2012 22:53:25 +0200

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

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

From: Russ Allbery <rra@debian.org>

To: Guillem Jover <guillem@debian.org>

Cc: 71621@bugs.debian.org

Subject: Re: Bug#71621: Policy on update-alternatives still needed

Date: Sun, 23 Sep 2012 14:04:20 -0700

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/>

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

From: "Graf LTD" <jweith@gmx.de>

To: "71621" <71621@bugs.debian.org>

Subject: Arbeitsagentur Aufgaben ab sofort

Date: Mon, 9 Feb 2015 03:01:10 GMT

Sehr geehrte Damen und Herren,

wir sind ein führendes europäisches Unternehmen und sucht im Augenblick motivierte Arbeitskollegen zur Vervollständigung des Teams europaweit. 

Die Dienste werden Eu weit gebraucht, und Sie haben die Möglichkeit unabhängig von Ihrem Wohnort anzufangen. Wir bieten Arbeitsstellen für jeden. Die Arbeitsstelle kann sowohl von Rentnern, Hausfrauen als auch nebenberuflich ausgeführt werden. 
Verpackungsaushilfe, Sekretärservice, Bewerter, und vieles mehr wird derzeit angeboten. 

Es werden Ihnen aktuelle Arbeitsangebote und die entsprechende Bezahlung angeboten und Sie entscheiden sich. Jede Tätigkeit wird verschieden bezahlt, im Schnitt verdienen Sie bei 3-5 Stunden am Arbeitstag 1400 bis 2000 Euro Brutto im Monat. 
Sie haben keinerlei Ausgaben und können sofort bei uns einsteigen. 

Kennummer NNL23978925 Es sind 14 offene Jobs zu besetzen. 

Die benötigte technische Ausrüstung wird von uns frei zur Verfügung gestellt. Die Stelle kann gerne von Rentnern, Hausfrauen und auch nebenberuflich ausgeführt werden. 
Was Sie mitbringen sollten wären technische Grundkenntnisse im Umgang mit der Kamera, Ehrlichkeit, Zielstrebigkeit, Flexibilität, Freundlichkeit
Wenn wir Ihr Interesse geweckt haben, schicken Sie uns Ihre vollständigen Bewerbungsunterlagen noch heute, gerne per E-Mail an: noythypueni@swedenmail.com Sie erhalten umgehend weitere Unterlagen zugeschickt. 


Wir freuen uns auf Ihre Bewerbung.

In Erwartung Ihrer Antwort Ihre

Graf LTD
Rue Gomboust 63
Brest 3538

Message #108 received at 71621-close@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: 617938-close@bugs.debian.org, 688363-close@bugs.debian.org, 821363-close@bugs.debian.org, 192571-close@bugs.debian.org, 215549-close@bugs.debian.org, 263448-close@bugs.debian.org, 276160-close@bugs.debian.org, 408500-close@bugs.debian.org, 562863-close@bugs.debian.org, 587377-close@bugs.debian.org, 592564-close@bugs.debian.org, 656569-close@bugs.debian.org, 663917-close@bugs.debian.org, 683570-close@bugs.debian.org, 684673-close@bugs.debian.org, 697134-close@bugs.debian.org, 704233-close@bugs.debian.org, 727754-close@bugs.debian.org, 737559-close@bugs.debian.org, 795783-close@bugs.debian.org, 832654-close@bugs.debian.org, 71621-close@bugs.debian.org, 120418-close@bugs.debian.org, 267142-close@bugs.debian.org, 291631-close@bugs.debian.org, 338219-close@bugs.debian.org, 375502-close@bugs.debian.org, 391240-close@bugs.debian.org, 397939-close@bugs.debian.org, 400112-close@bugs.debian.org, 412668-close@bugs.debian.org, 431109-close@bugs.debian.org, 457364-close@bugs.debian.org, 458824-close@bugs.debian.org, 462996-close@bugs.debian.org, 465140-close@bugs.debian.org, 466550-close@bugs.debian.org, 485559-close@bugs.debian.org, 491055-close@bugs.debian.org, 492144-close@bugs.debian.org, 521810-close@bugs.debian.org, 525843-close@bugs.debian.org, 528453-close@bugs.debian.org, 535577-close@bugs.debian.org, 541872-close@bugs.debian.org, 543417-close@bugs.debian.org, 549910-close@bugs.debian.org, 554194-close@bugs.debian.org, 570141-close@bugs.debian.org, 572571-close@bugs.debian.org, 580135-close@bugs.debian.org, 593177-close@bugs.debian.org, 610298-close@bugs.debian.org, 633994-close@bugs.debian.org, 660705-close@bugs.debian.org, 642914-close@bugs.debian.org, 663762-close@bugs.debian.org, 671503-close@bugs.debian.org, 681289-close@bugs.debian.org, 685992-close@bugs.debian.org, 690495-close@bugs.debian.org, 694384-close@bugs.debian.org, 775318-close@bugs.debian.org, 798714-close@bugs.debian.org, 524461-close@bugs.debian.org, 555981-close@bugs.debian.org, 682282-close@bugs.debian.org, 686143-close@bugs.debian.org, 515837-close@bugs.debian.org, 779506-close@bugs.debian.org, 628174-close@bugs.debian.org, 661417-close@bugs.debian.org, 681562-close@bugs.debian.org, 490605-close@bugs.debian.org, 647570-close@bugs.debian.org

Subject: Closing inactive Policy bugs

Date: Fri, 11 Aug 2017 12:44:51 -0700

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.