Bug#512920: apt: installation depending upon urgency
(CCing the aptitude bug as well, but this reply is based on the report to apt).
Hi,
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@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@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@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@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
"hamm-updates".
-- J.H.M. Dassen (Ray) <jdassen@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@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
172
$ 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.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: