Hi Francesco,
Francesco Poli wrote:
> > 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...
Ack.
> > 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.
I think I forgot some context: I'm using apt-listbugs together with
automatically applying updates. I only see the result later in cron
job mails or in the monitoring.
> 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...
Actually another thing which annoyed me in the past, but I haven't
checked if it's still the case, but IIRC apt-listbugs in unattended
upgrade mode (at least in the past) has put packages completely on
hold instead of just forbidding to upgrade to an affected version.
> > 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.
That's fair. Actually I was torn between important (as not having such
a feature causes false positives on holding back security updates) and
wishlist (because it _is_ a new feature which is necessary to fix this
issue).
> > * Check on which release it is running.
>
> Which can be done, but is not always trivial.
True.
> For instance: how do I tell testing (currently "bookworm") and unstable
> ("sid") apart?
The admin can set a preferred release via APT::Default-Release. That's
one source for a decision. If this is not set, the output of
"apt-cache policy" without a parameter should give an idea. If
multiple repos with different releases are at the highest rank, that
logic probably should be skipped.
> 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"?
Maybe skip that logic all together. At least my use case for that is
mostly security updates in stable vs tagged bugs in unstable.
> What about stable (currently "bullseye") with many packages backported
> from testing or unstable?
That's clearly bullseye then IMHO. (Given that these backports are
official ones. Otherwise they probably wouldn't come via (offiial) apt
repos.
> > * 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.
Yep. But then again this seems to happen rather seldom to me.
> 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.
Good point. At least the GNU project also uses debbugs. Not sure if
it's only used for upstream work or if also some Debian derivates
(Trisquel comes to my mind) use it.
> This would mean even more maintenance on the side of anyone who would
> port apt-listbugs to that distribution...
Ack.
> 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.
Understandable.
> > 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).
Correct. But many of us have to do that. That's also why release names
are announced two releases in advance.
But I like Adrian's distro-info-data idea here. That package also lists
Ubuntu releases, not just Debian releases.
> 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 see.
> 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.
Sure. Maybe time shows new ideas and possibilities. I'd appreciate if
you leave that bug report open for such thoughts.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
