Control: severity -1 wishlist
On Sun, 30 Oct 2022 11:30:58 +0100 Axel Beckert wrote:
> Package: apt-listbugs
> Version: 0.1.35
> Severity: important
>
> Hi,
Hello Axel,
nice to read you.
>
> apt-listbugs doesn't seem to care about release-related tags in the BTS,
> e.g. shows RC bugs on stable which are tagged sid and (currently)
> bookworm in the BTS and hence don't apply to the same (or similar)
> version in stable.
That's true, it does not take those tags into account.
It has a "-T" option to filter by tags, but I don't think it's too
useful in your use case, since you want to see bugs without
release-related tags plus bugs with the release-related tag which refers
to your own release...
> This causes false positives and unnecessarily blocks
> backported security updates of rolling-release packages like
> firefox-esr, chromium, etc. as well as updates of packages in
> <release>-backports.
Frankly speaking, I have really rarely encountered such a situation
myself. Hence, I have never felt an actual need for a special treatment
of release-related tags...
However, when you encounter a situation like the one you described, you
may take a look at the bug report (which is often a good thing to do,
before deciding whether to pin the package or go ahead with the
upgrade/installation) and immediately find out that the bug does not
affect your system.
At that point, you may dodge (command 'd') any other bugs that worry
you, and proceed with the upgrade/installation of the package affected
by the other-release-specific bug. Or mark the other-release-specific
bug as ignored (command 'i'), if you prefer.
I acknowledge that this requires manual intervention and human
judgment, but they are also needed for other kinds of bugs, unless you
want to pin *any* buggy package, no matter what...
>
> One such recent example is #1021810 in firefox-esr which is about
> dropping 32-bit architectures in the future. (Granted, the result of
> that specific discussion-style bug-report will probably also apply to
> stable at some point, but that's not the point here. :-)
>
> So from my point of view, apt-listbugs should do the following:
Thank you for this feature request.
I am setting the severity to "wishlist", since you are requesting the
implementation of a new feature.
Please let me comment on what you propose.
>
> * Check on which release it is running.
Which can be done, but is not always trivial.
For instance: how do I tell testing (currently "bookworm") and unstable
("sid") apart?
With some pin-priorities set, it is easy to run a mix of the two.
So: how should I consider testing with some packages from unstable (or
even experimental)? as "bookworm"? or as "sid"?
What about stable (currently "bullseye") with many packages backported
from testing or unstable?
>
> * Only take RC bugs into account, which are either not tagged for any
> release at all (and where hence only the affected versions are
> relevant) or which are (also) tagged for the current release.
>
> To do that it seems only marginally necessary how other releases a named
> as it only needs to know the release name of the release its running
> on. For that it should suffice to know a list of all tags which are
> _not_ release names.
This would require heavy maintenance on my side, since I would need to
be very prompt to update this list, as soon as a new
non-release-related tag is added to the Debian BTS.
Moreover, other Debian-based distributions could decide to use a BTS
based on debbugs (I don't know whether there are any _today_, but there
could be some _in the future_), and they could use a slightly different
version of debbugs or a fork with different non-release-related tags.
This would mean even more maintenance on the side of anyone who would
port apt-listbugs to that distribution...
All this looks a bit fragile: for instance, suppose a new
non-release-related tag is implemented in the Debian BTS (I think the
last addition was 'newcomer') and apt-listbugs is not promptly updated
to recognize that new non-release-related tag. An unaware apt-listbugs
would consider any bug tagged with this new tag ('newcomer') as
specific to this non-existent release ('newcomer') and users running,
say, unstable would fail to be warned about those bugs...
I am somehow reluctant to implement such a fragile feature.
>
> Then again, if new not-release-name tags are added to the BTS in the
> future, having a positive list of all known release names (which are
> usually known two releases in advance) might be helpful nevertheless.
[...]
This could be slightly better, but would require maintenance on my side
anyway, as new release names are continuously added (roughly every
second year).
However, this approach would be even more Debian-specific and would
require a fork of apt-listbugs for any other Debian-based distribution
which uses a debbugs-based BTS...
All in all, I see the usefulness of the feature you are requesting
(although it seems to be somewhat limited), but the proposed
implementation strategy looks a bit fragile and troublesome...
I won't be able to think about a possible better strategy until after
bookworm is out and, anyway, I cannot promise you that this feature
will actually be implemented, unfortunately.
Sorry about that.
--
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
pgpFQ8uGwsT6g.pgp
Description: PGP signature
