Bug#169361: ITP: apt-listbugs -- Retrieves bugs from BTS and lists them
On Sun, Nov 17, 2002 at 06:46:26AM +0900, Masato Taruishi wrote:
> According to BTS (currently it needs to use other programs like querybts),
> these bugs are fixed in 1:2.95.4-15.
But does apt-listbugs attempt to determine this information automatically?
If so, how? I do not see how this information can be accurately obtained
from the current BTS.
> 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.
> > 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?
> 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?
--
- mdz
Reply to: