(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.ho...@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 <gal...@micron.net> Tue, 31 Dec 1996 22:15:03 -0700 dpkg (1.4.0) unstable; urgency=low (HIGH for new source format) [...] -- Ian Jackson <i...@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 <lawre...@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) <jdas...@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 <to...@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.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org