Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
At Sat, 16 Nov 2002 17:49:22 -0500,
Matt Zimmerman wrote:
> > Once I upgrade the package, some bugs are no longer displayed.
> >
> > vass% sudo apt-get --reinstall install libstdc++2.10-glibc2.2
> > Reading Package Lists... Done
> > Building Dependency Tree... Done
> > 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
> > Need to get 0B/130kB of archives. After unpacking 0B will be used.
> > Do you want to continue? [Y/n]
> > Critical bugs of libstdc++2.10-glibc2.2
> > (#169042) Upgrading libstdc++ breaks lots of stuff
> > (#160977) suck: Broken handling of per-host configuration with the option -AL
> > Grave bugs of libstdc++2.10-glibc2.2
> > (#169072) base: typo in library-dependencies for glibc
> > Are you sure to install/upgrade these packages? [Y/n]
>
> What is different about these bugs, vis a vis the others that are no longer
> displayed? Indeed, two of these are duplicates of the bugs which were
> shown in the previous run.
These bugs are displayed because apt-listbugs can't determine
what version the bug is assigned (No 'optional' Version: header
is found, or the bug is reassinged from other packages etc.)
> > > How will it determine whether the bug actually applies to the version of the
> > > package being installed? Or will it rely on the user's manual review to
> > > approve every package?
> >
> > apt-listbugs does a non-accurate analysis to determine that the bug applies
> > to the version. This tool is expected to save many machines from broken
> > packages and not to flood many bug reports which is the same bug as many as
> > possible.
> >
> > In upgrade phase, the following situations are under considerations:
> >
> > submit current new
> > --------------------------------->
> >
> > In above situation, you have already gotten the bug -> not care.
> > (submit means the version where the bug has been submitted)
> > You can select whether apt-listbugs list it or not. It doesn't
> > list it by default.
> >
> > current new submit
> > --------------------------->
> >
> > In above situaion, the new package maybe doesn't have the bug yet.
> > You can select whether apt-listbugs list it or not. It doesn't list
> > it by default.
> >
> > current submit new
> > --------------------------->
> >
> > In above situation, the new package may have the bug (it may be
> > fixed and still archived in BTS).
> > Currently apt-listbugs lists it.
>
> This is not entirely clear, but it sounds like you are comparing the
> (optional) Version: header in the original BTS report against the package
> version. Is this what you are doing?
Yes, it's optional. So the above bugs are displayed. Is there
another solution to compare? I want to adapt it.
> > I guess the above simple algorithm can probe most of critical (I mean this
> > is not a term of serverity) bugs. apt-listbugs isn't a tool that lists
> > accurate bugs that actually apply to the version, but that warns that the
> > version may have critical bugs. At least it's useful for me.
>
> This is an interesting idea, though it involves a lot of guesswork with the
> data that is available. Is it significantly better than simply listing the
> open RC bugs for the packages?
Hmm, do you have a tool to simply list the open RC bugs before
the upgrade?
Basically apt-listbugs is similar as such tools, it simply
and only listed RC bugs before. But one problem is that the
information of 'open RC bugs' is for the latest packages. The
version may not be mirrored to your mirror site yet. That's
just what I faced :( So it now optionally does more guesswork.
Reply to: