NBS removals of old kernels from stable -security and -updates pockets

[Dimitri John Ledkov]

On Tue, 25 Apr 2023 at 10:06, Steve Langasek <steve.langasek at ubuntu.com> wrote:
>
> Hi folks,
>
> Kernel updates have an interesting property that, unlike most SRUs, the
> binary package names change for each update, because the ABI is presumed to
> change each time.
>
> The result of this is that each kernel update causes the binary packages
> from the previous version to become "NBS" (not built from source).
>
> Cleanup of NBS packages from the archive is a manual process involving
> Archive Admins; they are not automatically removed from the archive.  And
> historically, we did not want to remove NBS kernel packages during a release
> cycle, because our netboot images relied on modules of matching ABI being
> available in the archive corresponding to the kernel ABI used in the netboot
> image - and as we did not control when our users deployed netboot images on
> their infrastructure, we did not want to arbitrarily break working customer
> systems, we did not remove NBS kernel packages as we went - only at EOL of a
> release.
>
> However, netboot images that rely on kernel packages of a matching ABI being
> available in the archive are an artifact of debian-installer, and as of
> jammy, we no longer ship debian-installer.  Therefore, this rationale for
> retaining the old kernel binary packages in the archive no longer exists.
>
> Nearly 50% of all binary packages published in the jammy-updates pocket
> today are from kernels[1], and this proportion only increases as an LTS
> ages.  I have not done the analysis, but I expect the kernel packages to
> represent a similar or higher proportion of the *size* of the -updates
> pocket.  Thus, keeping these old binary packages around impacts both the
> speed of `apt update` for both -updates and -security pockets, and the size
> of the mirror set for these releases.
>
> I am therefore intending that, for jammy and later releases, we start to
> prune NBS kernel packages on an ongoing basis, not just at EOL time.

For a while I have been pondering about facilitating this too.

In the Launchpad API, we have a "move" parameter to the copyPackage()
API  (Move - If true, delete the source publication after copying it
to the destination.). I was thinking of potentially adding a "replace"
parameter to the copyPackage() API (Replace - If true, delete previous
destination publication after copying a new one). This would be very
helpful for kernel publication in devel series too, as frequently a
lot of NBS end up in -proposed from unmigrated (with move=True) ABIs.

Would SRU/Archive teams find that helpful, and should I attempt to add
this to Launchpad?

-- 
okurrr,

Dimitri