Hi Francesco, On 2016-05-25 19:35:48 +0200, Francesco Poli wrote: > Please read section 'Why does apt-listbugs ignore the "affects" field?' > in /usr/share/doc/apt-listbugs/README.Debian.gz : you'll find a detailed > and (hopefully) clear explanation of the rationale behind the > deliberate choice to ignore the "affects" field.
Well, I disagree on what is written (so does the Debian website, BTW). Let me explain. My case is scenario 1. It is said: In scenario 1, stopping an upgrade to A/a1 would actually be useful, as it would prevent the bug from showing up. However, the "affects" field does not carry any version tracking information, unfortunately. Even though the "affects" field does not carry any version tracking information, it probably affects the current version or later. If the current version is no longer affected, then the "affects" field should probably be removed from the bug report. Note also that when there's an RC bug against a package, it doesn't necessarily affect the user, i.e. the user has to check (but at least, he has been warned). https://www.debian.org/Bugs/server-control.en.html#affects says: [...] This should generally be used where the bug is severe enough to cause multiple reports from users to be assigned to the wrong package. which is precisely the case here. RC bug #825111 had been reported with "affects" to qtchooser. When I try to upgrade qtchooser, the upgrade fails due to this bug. As I didn't know about this bug and got no warnings from apt-listbugs, I reported a RC bug against qtchooser (#825243), which was actually a duplicate of #825111. The apt-listbugs README.Debian file also says: And there's no way for apt-listbugs to distinguish between scenario 0 and scenario 1, either. I don't think this is true: apt-listbugs could look at the version of B installed and look at the found/fixed fields of the bug. Here the buggy B/b1 was already installed. Anyway the apt-listbugs behavior defeats the purpose of the affects field as described on the Debian web page. The apt-listbugs README.Debian file also says: There's a way to work around the lack of version tracking info for the "affects" field: whenever you find yourself in scenario 1, file a separate bug report against package A, marking it as found in version a1 and as blocked by the actual bug report (the one assigned to package B). This was partly what I did when I reported #825243, except that I didn't know the other bug (in particular, the buggy package couldn't know that it would break a future version of qtchooser). But the developer reassigned my bug instead of doing what is suggested above. Perhaps this workaround could become official? This would avoid bugs being reassigned by developers. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
