Bug#642757: apt-listbugs

[Francesco Poli]

On Tue, 18 Oct 2011 23:45:03 +0700 Alexey Salmin wrote:

> Thank you, Francesco!

You're welcome!   :-)

[...]
> On Tue, Oct 18, 2011 at 2:37 AM, Francesco Poli
> <invernomuto at paranoici.org> wrote:
[...]
> > In your example, if I understand correctly, you upgrade
> > nvidia-graphics-drivers and crash xserver-xorg-core.
> > This is described by the fact that bug #642757 is assigned to
> > nvidia-graphics-drivers, but affects xserver-xorg-core.
> >
> No! That's the whole point! You upgrade xserver-xorg-core from 2:1.10
> to 2:1.11 and your desktop dies because of a bug in
> nvidia-graphics-drivers.

Ah, OK.
I thought it was the other way around: I hadn't found the time to read
the whole log of bug #642757, sorry.

> If the issue was caused by an upgrade of
> nvidia stuff everything would be fine: there's a bug in the nvidia
> package and apt-listbugs warns you about it during the upgrade.

Exactly.

> But
> it's not that way in this case. There's a bug in one package and it's
> exposed by a new version of another. Probably that's a common scenario
> e.g. a bug in a script could be exposed by a newer version of
> interpreter or vice a verse. In this case you'll not get a warning
> from apt-listbugs at all.

True.
I don't know how common this scenario is, but it's true that
apt-listbugs is not able to save your day when that happens!
Unless an auxiliary bug report is filed against the package that should
not be upgraded, I mean.

> 
> There're some ideas coming into mind how to solve it:
[...]
>
> * Create a dummy bug report on xserver-xorg-core saying e.g.
> "xserver-xorg-core 2:1.11 is incompatible with nvidia-graphics-drivers
> 285.05.09-1"
> It may help a bit but:

I think that, currently, this is the best course of action.

Since xserver-xorg-core/2:1.11.1-1 is already in testing, a bug report
of severity grave against version 2:1.11.1-1 should not prevent future
migrations to testing of newer xserver-xorg-core versions (please
correct me, if I am wrong).

This bug report could be marked as blocked by #642757.
It will be possible to close it, as soon as a fixed version of
nvidia-graphics-drivers has migrated to testing.

> - Somebody should care enough to create such bug reports and close
> them as appropriate.

True, but it seems that a good number of people care about this issue...

> - I doesn't depend on the actual version of nvidia-graphics-drivers
> installed so it will show up in the cases it shouldn't.

Sure: a good descriptive bug report title would help users to determine
whether they may ignore the issue or not.

> 
> * Make use of the "642757 affects xserver-xorg-core" record
> That was my original idea but it will not work as is because AFAIK
> currently there's not way to specify the version of package affected
> by some bug. So if someone have a nvidia-graphics-drivers=285.05.09-1
> installed he'll be warned at ANY update of the xserver-xorg-core (even
> when he makes a downgrade workaround) which is just useless.
> 
> MY SUGGESTION IS:
> - Extend the "affects" record in the BTS to store the version of the
> package affected

Maybe two entirely new BTS commands should be created, with mandatory
version info. Something like "exposed by" and "hidden by" (a better name
should perhaps be chosen).
That way, it could be agreed that:

bug #nnn (assigned to package B, found in version v1) affects package A
means that
the bug is actually present in B/v1, but causes breakage in package A
hence, do not upgrade to B/v1 or later, if you want to avoid breaking
package A

bug #nnn (assigned to package B, found in version v1) is exposed by
E/v2, is hidden by E/v3, is exposed by E/v4
means that
the bug is actually present in B/v1, but only shows up when a version
of package E which exposes the bug is installed
hence, do not upgrade to E/v2 or E/v4, if you want to avoid exposing
the bug in package B (it is however safe to upgrade to E/v3)

The versions of package E used in "exposed by" and "hidden by" would be
treated exactly like version tracking (which is driven by the "found"
and "fixed" commands): in other words, the changelog would be used to
determine the most recent descendant of version v, among the listed
"exposed" and "hidden" versions, and this descendant would determine
whether version v exposes or hides the bug. 

> - Implement a feature in the apt-listbugs to make use of this records
> 
> I'll try to express this with more details:
> 1) There packages A of version X and B of version Y installed
> 2) You're trying to upgrade package B to version Z
> 3) There's a bug report NNN on package A=X and it "affects B=Z"
> 4) In this case apt-listbugs should warn you before upgrading B to Z
> 
> What do you think?

I think that, if the above idea looks good to you and others, maybe the
opinion of debbugs developers should be asked.
If they think it's OK, a proper wishlist bug report should be filed
against the debbugs package.
Only after this new feature is implemented in the BTS, I will be able
to make use of it in apt-listbugs...

Anyway, as said above, the simplest workaround is filing a dummy
auxiliary bug report against the package E, and thus use the already
implemented BTS version tracking to see which versions of E expose the
actual bug in package B.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20111020/0eaf09cd/attachment.pgp>