Re: Debian 10 backports repo moved to archives
On Mon, Apr 15, 2024 at 10:31:43AM -0700, Zach Marano wrote:
> It seems that the Debian 10 backports repo (buster-backports) moved out of
> the main Debian repos and into the archives ahead of the intended LTS EOL
> date (June 30, 2024). I don't recall this type of change happening with
> Debian 9 when it was in this phase. For cloud images, we currently have
> the backports repo added to all the cloud images
> ([1]https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/config_space/bullseye/files/etc/apt/sources.list/DEBIAN?ref_type=heads#L7).
> Given the short timeframe for the remainder of Debian 10's LTS period,
> what do you think we should do for this instance.
I believe the intent was for it to be covered by the announced move of
buster to archive.debian.org. [1]
Also, although it's not super prominent, the backports instructions page
indicates that "old-stable-backports are only made available for a
period of one year after a new Debian stable release has been made".
[2] So based on that, it would seem that the removal of
buster-backports was overdue, and should have happened a year after
bullseye was released in Aug 2021.
> Also, going forward it seems we may need to adopt a different set of
> configuration for LTS versions to avoid this type of thing. I recall the
> discussion about supporting the LTS versions in cloud images several years
> ago but I'm not sure if we fully aligned on what that support means.
> Perhaps dropping backports should be part of that transition?
The Debian cloud team also builds and ships images with buster-backports
enabled, and will need to deal with this change.
What are the specific packages that Google wants from the backports
repo by default? From my perspective, the primary reasons to enable it
are for backports kernels (which have historically provided a number of
performance and driver updates of interest to cloud customers) and for
cloud SDKs and tools.
For the kernel, I think the backports repository remains the best path
forward as long as it exists. Especially since backports kernels get
moved to the security repo for ongoing maintenance in the LTS branch.
For cloud SDKs and tools, though... This remains an unsolved problem.
We can discuss this in this week's cloud-team Jitsi meeting, but we'll
likely need release team involvement in any final solution.
noah
1. https://lists.debian.org/debian-devel-announce/2024/03/msg00003.html
2. https://backports.debian.org/Instructions/
Reply to: