On Tue, 25 Apr 2023 at 10:06, Steve Langasek <[email protected]> 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 -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
