[Aptitude-devel] Bug#325015: apt: installation depending upon urgency

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Sat Feb 8 12:33:08 UTC 2014

(CCing the aptitude bug as well, but this reply is based on the report to apt).


For whatever is worth, I don't think that this is a matter that should
concern apt, and so I don't think that this feature should be added.

The urgency field is not intended as a documentation for the user (and
indeed, I think that it's better that would not be easily visible to
users, since it's often misleading).  Maybe it was so in the past, but
even if it would be valid syntax today, the most recent use of it in
important packages was in the last century:

gcc (2.95.2-0pre2.0.2) unstable; urgency=HIGH (for m68k)
  * Binary-only NMU for m68k as quick fix for another bug; the patch
    is in CVS already, too.
  * Applied another patch by Andreas Schwab to fix %a5 restauration in
    some cases.
 -- Roman Hodek <Roman.Hodek at informatik.uni-erlangen.de>  Thu, 30 Sep
1999 16:09:15 +0200

binutils (2.7-5) unstable; urgency=low (HIGH for m68k)
  * Added patch for m68k, will now compile X68 and kernel 2.1.15
 -- Galen Hazelwood <galenh at micron.net>  Tue, 31 Dec 1996 22:15:03 -0700

dpkg (1.4.0) unstable; urgency=low (HIGH for new source format)
 -- Ian Jackson <ian at chiark.greenend.org.uk>  Thu, 12 Sep 1996 01:13:33 +0100

libjpeg6b (6b-1.2) frozen unstable; urgency=low (HIGH for m68k)
  * Non-maintainer release.
  * Recompile for m68k since existing djpeg binary claims all jpegs I have
    are invalid (yet hamm djpeg has no problem with them).
    Specifically, added "-O2 -g -Wall" to CFLAGS -- possible gcc bug?
 -- Chris Lawrence <lawrencc at debian.org>  Tue, 10 Nov 1998 20:57:38 -0600

ncurses (1.9.9g-8.9.1) stable; urgency=high (security fix)
  * Previous upload got rejected. Set distribution to "stable" instead of
 -- J.H.M. Dassen (Ray) <jdassen at wi.LeidenUniv.nl>  Wed, 29 Jul 1998
14:22:50 +0200

perl (5.004.04-3) unstable; urgency=medium (High for those upgrading from bo)
 -- Darren Stalder <torin at daft.com>  Tue,  9 Dec 1997 12:21:48 -0800

Stats in my system (with repeated entries, e.g. of the several binary
packages from gcc):
$ grep '; urgency=.*(' /tmp/changelog-all | wc -l

$ grep '; urgency=.*(' /tmp/changelog-all | cut -d' ' -f1 | sort | uniq -c
      1 binutils
     32 dpkg
     60 egcs
     45 gcc
      2 libjpeg6b
      1 mutt
     27 ncurses
      4 perl

Currently I think that the only use of it, apart from perhaps hinting
the buildds or the FTP team somehow (but don't think so), is to decide
the time of migration from unstable to testing or similar scenarios.
That's why it's in the changelog and intended for archive tools,
instead of being a field in the package.

But even if desired to communicate with the user, it's not simple to
achieve with a single keyword.  It can be perfectly possible that a
new upstream release fixes important bug fixes and provides new
functionality, thus the user would want to install it, but still have
"urgency=low" because the maintainer thinks that there should be 10
days of "quarantine" from unstable to testing (in the case that there
are RC bugs stopped, which hold the migration), instead of 5 days for
medium or only 2 for high.

In the example mentioned in the initial bug report, urgency would not
be used as in the example of the holidays, but only as a "how
important is to update it compared to the last version", which is
completely different.  When one adds multiple versions to the mix, you
need "versioned" recommendations:

9.6-1  recomm: high
9.8-1  recomm: medium # only translation fixes since 9.6
9.8-2  recomm: high (<9.8), medium (>=9.8)
10.0-1  recomm: high
10.2-1  recomm: high
10.2-2  recomm: high (<10.2), low (>=10.2)

Because otherwise, if there's only a field compared to the latest
entry (and currently, urgency is a "single entry"), a person having
version 9.6 installed, and not updating the packages list until 10.2-2
is present, doesn't know if it's "recommended" to update or not unless
it interprets the whole chain between the installed version and the
most recent one.

On the other hand, the changelog entries as explanatory and intended
as a means of communication maintainer<->user, to decide if the
changes contained are worth downloading and upgrading to the new
version.  But this cannot be automated by the interpretation of a
machine, the user must decide.

Summary: "urgency" is not intended as a recommendation of upgrades for
the user (even if sometimes can be interpreted as such; and often
misinterpreted), and the meaning cannot be overloaded as in the
example of the original bug report as a means of communication
maintainer<->user.  The changelog entries are.  So I don't think that
this feature should be implemented.

Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>

More information about the Aptitude-devel mailing list