On Fri, 27 May 2016 00:36:01 +0200 Vincent Lefevre wrote: > On 2016-05-26 23:57:10 +0200, Francesco Poli wrote: > > On Wed, 25 May 2016 20:44:09 +0200 Vincent Lefevre wrote: > > > 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. > > > > Wait, what does "current" mean? > > Please think about it. > > > > Current in Debian testing? in unstable? in unstable+experimental? > > Any. There could be false positives, but false negatives would be > avoided.
In order to avoid false negatives, the "affects" field should be
removed *only* when all versions become unaffected (where 'all' means
experimental, unstable, testing, stable, oldstable, lts, ...).
Then, there would be *so many* false positives, that this potential
feature of apt-listbugs would do more harm than good.
Really: apt-listbugs is useful as long as it takes advantage of BTS
version tracking info, in order to be as accurate as possible, when
determining which bugs are introduced into a given system by which
versions of which packages.
>
> > One has to also take into account that some users use apt-listbugs
> > on Debian stable systems, which further complicates the possible
> > situations.
>
> Well, perhaps ignore stable and oldstable systems: they are not
> supposed to have RC bugs, or occurring RC bugs are regarded as
> acceptable.
Except that stable and oldstable systems do have RC bugs, regardless of
what they are supposed to have.
I think that ignoring them would be plain arbitrary...
>
> > I do not think that what you reported is indeed a duplicate of the
> > bug assigned to qtbase-opensource-src.
> > As explained in the cited README section, your bug report
> > should request the addition of an appropriate
> > "Breaks: libqt5core5a (<< 5.6.0+dfsg-3)" to package qtchooser.
>
> When I reported the bug, I didn't know that the fix would be in a
> separate package, i.e. I thought that qtchooser really did a wrong
> thing.
This happened because you didn't see the bug that affected qtchooser,
before preparing your own bug report.
This makes for a wishlist bug against package reportbug, see below.
> Only when some developer explained ("qtchooser is affected
> by this bug, but libqt5core5a/src:qtbase-opensource-src is doing
> the wrong thing, therefor the bug is in src:qtbase-opensource-src")
> I said that qtchooser should have had a Breaks:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825243#46
You could report a separate bug requesting the addition of the "Breaks"
field, unless the maintainer of qtchooser is annoyed by this...
>
> > > 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.
> >
> > It is possible to check that the buggy B/b1 is already installed.
> >
> > In scenario 0, this means that the breaking of package A is already
> > going on in the system (before the upgrade of A).
> >
> > In scenario 1, this means that the breaking of package A will only
> > happen, after the upgrade to A/a1.
> >
> > As you can see, knowing that the buggy B/b1 is already installed
> > does not help in figuring out which scenario the user is facing.
>
> In the README.Debian file, it is said for scenario 0: "do not upgrade
> to B/b1 if you want to avoid breaking package A". The "do not upgrade
> to B/b1" implies that B/b1 is not already installed for this scenario.
> If this is not the case, this README.Debian file should be clarified.
I think it's clear that "do not upgrade to B/b1" implies "if it is not
already too late".
In other words, in scenario 0, the breakage in package A is caused by
B/b1: hence, if you haven't yet installed (or upgraded to) B/b1, you
may want to wait (and apt-listbugs will give you an opportunity to
do so).
If, instead, you already have B/b1 in your system, the damage is done:
there's no point in stopping the upgrade of A.
Both cases belong to scenario 0, though.
Hence, check whether B/b1 is installed does not help in distinguishing
scenario 0 from scenario 1.
>
> > > Anyway the apt-listbugs
> > > behavior defeats the purpose of the affects field as described
> > > on the Debian web page.
> >
> > Not exactly: the purpose of the "affects" fields, as stated on
> > Debian website page, is to prevent "multiple reports from users"
> > from being "assigned to the wrong package".
> > The user experiences the issue with qtchooser, and checks whether
> > it has already been reported. The bug page for qtchooser [1],
> > also lists bug #825111, hence further duplicate bugs should be
> > prevented.
>
> For obvious RC bugs (installation failures), I expect to get reports
> from apt-listbugs, so that I never check the web pages.
apt-listbugs has no way to distinguish installation failures from other
RC bugs...
> Moreover, I
> always use "reportbugs", so that I can check again the reported bugs,
> but reportbugs also appears to ignore "affects"!
[...]
As I said above, this could be a wishlist bug against package reportbug.
Feel free to file a bug report against reportbug.
Bye and thanks for using apt-listbugs.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpUcbpQIY528.pgp
Description: PGP signature
