As announced in
https://lists.debian.org/debian-backports-announce/2024/07/msg00000.html,
bullseye-backports no longer accepts uploads and should not be expected to
be up-to-date with bookworm{,-security}. I think it would make sense to
drop it from the "versions" and "versioned links" panels on the package
tracker at this point.

(For future branches, this happens at the same time that the base suite is
handed over from the security team to the LTS team, approximately 1 year
after the next stable release. For example, bookworm-backports'
end-of-life will be about a year after the trixie release, at which
point it will stop accepting packages backported from trixie{,-security}.)

    smcv

Hi,

Why?

I mean it doesn't disappear from the rmadison output either, and I see
that table as a web version of "rmadison".

I typically remove tracking of such distributions when they are no
longer available on the local mirror and when jobs are failing due to
that. :-)

So arguably the question could become "why do we keep repositories that
we can't update on ftp-master.debian.org"?

FWIW, the LTS team agreed with security team and release team to say that
the handover happens 3 years after the release, and no longer 1 year after
the next stable release. I guess the backports team could follow the same
logic... though to be fair, I'd prefer if DD were allowed to maintain
backports 5 years if that's their wish.

Cheers,

Hi Raphael,

I'm responding here as member of the backports team -- at least as good
as I can.
decision predates my deeper involvement in maintaining the backports
archive. But maybe the other backports-team members can chime in here.

One potential rationale that comes to my mind is: We might want to
reduce incentives for users of oldstable to stay on oldstable instead of
updating to stable. Also, we might want contributors to focus on the
next release instead of focusing on past releases, because given a
limited amount of resources every hour spent on past release is not
spent on the next release. Please note, this potential rationale is not
necessarily my own view -- it's rather some random speculation.

@formorer, would you mind to share your view on this topic?

Best regards,
Micha

Hi,

FTR, I'm not asking why backports is active only 3 years, I know the
rationale (mainly that backports are maintained by volunteers and that
when you introduce a backport you have the responsibility to maintain it
properly over the lifetime of the target release, and the team doesn't
want to impose 5 years to volunteers). I don't agree with it and the level
of expectation that is set on backport maintainers, and I believe it
doesn't really match the reality anyway as some backports are never
updated. But that's another debate.

I'm just asking "What does it gain us to hide the version that is
still available and installable from the no longer maintained repository ?".

Arguably, if I drop bullseye-backports, I should also drop buster. But I
don't see the value of that. As I said, this table is like "rmadison" for
me, it doesn't imply anything on the support level of any listed package,
it just documents what is available where.

Cheers,

Am Wed, Jun 04, 2025 at 10:35:51PM +0200 schrieb Micha Lenk:

Sure, the thing is simple. We asked around the time when LTS came up if people
want to maintain backports for over the LTS lifetime.  Consensus was that most
of the maintainers don't want to do that.

Alex

Perhaps such unsupported legacy distributions could get a light gray
background.

Andreas

Hi,

That's a possibility, but tracker.d.o is not supposed to be the
authoritative source for that information. Ideally it would come
for the repository metadata.

I have argued quite regularly that we should modify the "Release" file
to document the EOL date of the repository, and then have apt warn about
it, possibly linking to some helpful documentation.

https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/17

Someone should really bite the bullet and start the conversation with
ftpmasters and/or APT developers to define a proper field structure
for this.

(Arguably, we could also figure out some way to extract this from the
latest distro-info-data, but that still seems a work around to the lack
of the information in the right place)

Cheers,