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.
We don't actually rely on it for anything in GCE (for Debian 10 anyway). This is more of a - what do we want to do with Debian LTS releases and backports in cloud images question. Certainly there could be users who depend on packages from a backports repo and since it was available during the standard support phase, removing it could be considered a regression for them.
The question for the moment is, do we change the Debian 10 LTS cloud images to reference
archive.debian.org instead of
deb.debian.org for the backports repo (and the same going forward for LTS releases). And in doing so, is that going to cause infrastructure issues for
archive.debian.org? Or, do we remove the backports repo config entirely when a release enters the LTS phase and let users decide?
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/