Package: apt-listbugs Version: 0.0.89 Severity: normal Severity note: borderline between a bug and wishlist. Because of the possibilities for misinterpretation and consequent installation of broken software, I'm submitting this as a bug.
The problem seems easiest to describe with a concrete example. Today, apt-listbugs displayed grave bugs of python2.5 (2.5.2-6 -> 2.5.2-6+lenny1) <done> #493797 - python2.5: CVE-2008-2316 integer overflow in _hashopenssl.c (Fixed: python2.5/2.5.2-7 python2.5/2.5.2-11) grave bugs of lsb-base (3.2-12 -> 3.2-19) <done> #495587 - lsb-base: "fix" for killproc breaks many things (Fixed: lsb/3.2-20) Merged with: 494268 494943 The tempation, at least for me, is to interpret <done> to mean "problem solved; I can ignore the bug." In the first case, it is unclear whether 2.2-6+lenny1 resolves the problem, which is indicated as fixed in 2.5.2-7 and -11. I suspect the lenny version is a backport with the fix, but one can't tell (without looking elsewhere). The second case is more serious. The bug is <done>, but pulling in the planned upgrade will *introduce* the bug into the system in this case (currently installed version does not have the bug; 3.19 to be installed has it; 3.20 fixes it). While one could argue that there is no bug at all, since the information is there if all of it is studied closely (perhaps with some external checking), there is at least a usability issue. The problem is that the decisions the user needs to make focus on somewhat different information than is presented. The information presented is not as helpful as it could be, and is easily misinterpreted given the user's frame. At least for me, the main question is "should I accept the upgrade?" If the upgrade fixes an important bug, I want it. If it introduces an important bug, I don't. So the key info I need is whether the *version proposed for installation* either has or fixes a bug. Whether the currently installed version has the bug is also relevant. In contrast, the <done> or <pending> tags seem to refer to the state of the bug, rather than the particular versions of interest. The <pending> description is also unclear, even as a bug status, because it suggests that there is a fix, but that it hasn't been applied. I gather the actual meaning is simply that the bug is open. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (990, 'stable'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages apt-listbugs depends on: ii apt 0.7.14+b1 Advanced front-end for dpkg ii libdpkg-ruby1.8 0.3.2 modules/classes for dpkg on ruby 1 ii libgettext-ruby1.8 1.91.0-1.1 Gettext for ruby1.8 ii libhttp-access2-ruby1.8 2.0.6-3 HTTP accessing library for ruby ii libruby1.8 [libzlib-ruby1.8] 1.8.7.22-3 Libraries necessary to run Ruby 1. ii libxml-parser-ruby1.8 0.6.8-4 Interface of expat for the scripti ii ruby 4.2 An interpreter of object-oriented apt-listbugs recommends no packages. Versions of packages apt-listbugs suggests: ii debianutils 2.30 Miscellaneous utilities specific t ii iceweasel [www-browser] 3.0.1-1 lightweight web browser based on M ii konqueror [www-browser] 4:3.5.9.dfsg.1-5 KDE's advanced file manager, web b ii lynx-cur [www-browser] 2.8.7dev9-1.2 Text-mode WWW Browser with NLS sup ii reportbug 3.44 reports bugs in the Debian distrib ii w3m [www-browser] 0.5.2-2+b1 WWW browsable pager with excellent -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
