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