On Sun, 23 Sep 2012 22:51:37 +0200 Yann Dirson wrote: > On Sun, Sep 23, 2012 at 08:04:35PM +0200, Francesco Poli wrote: > > Control: severity -1 normal > > > > > > On Sun, 23 Sep 2012 19:43:57 +0200 Francesco Poli wrote: > > > > > On Sun, 23 Sep 2012 11:54:52 +0200 Yann Dirson wrote: > > [...] > > > > Severity: important > > [...] > > > (unless it fixes a release critical bug, but this one > > > is definitely not RC). > > > > By the way, I think the severity of your report is a bit inflated. > > This bug does not have "a major effect on the usability of" > > apt-listbugs. > > Well, given that multi-arch is a release goal for wheezy, we're > entering a blurry domain here :)
As far as I know, apt-listbugs *as a package* does not require modifications to let wheezy achieve the multi-arch release goal. This is distinct from the fact that apt-listbugs *as a packaged program* could provide a more detailed output (to users who enabled multiarch support on their systems) in order to be more useful than it currently is. I don't think that the latter fact should be regarded as something to be fixed in order to achieve the multiarch release goal. I may of course be wrong, possibly because, as I said, I am quite ignorant about multiarch... > > I guess a "level 0" support, like using the "arch qualified" package > name (or whatever the exact term is - that is, libfoo:i386 instead of > just libfoo, probably an info that can be queried from dpkg with > little change), could be something not too intrusive to add, and which > would even have the potential to be accepted into wheezy as > participating to the release goal ? I think that it's not that easy. apt-listbugs gets the names of the packages being installed/upgraded/... from the Pre-Install-Pkgs hook info pipe, with data conforming to the hook info protocol version 2. Please see http://bugs.debian.org/627188#68 for the proposed patch that documents this protocol in apt.conf(5) man page. Maybe the architecture may be guessed from the filename (in the action field), but all the consequences of doing this must be considered and evaluated, before applying such a change... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpkZGZn2ILSP.pgp
Description: PGP signature
