Re: Debian Kernel version and ABI in respect of #1040901
On Fri, Jul 14, 2023 at 04:17:34PM +0200, Ben Hutchings wrote: > On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote: > [...] > > ## Proposed behaviour > > > > This tries to make sure everything apart from experimental gets new > > names and ABI on every upload. > > > > * experimental: > > Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4 > > Keep ABI 6.1.0-0-arm64 > Why would that still be acceptable in experimental? What do you mean? We don't check for any ABI incompatibilities forever in experimental builds. And the signature check will refuse to load modules not from the same build if lockdown is enabled. So the ABI as listed in the image and the package just means it is provided in the same package and can be upgraded directly. We can also decide that we don't want to make it that explicit and do: ABI/package name only includes upstream version (6.1.1) and multiple Debian revisions of that will be incompable to each other on lockdown systems, but may work (depending on symvers) on non-lockdown systems. It does not happen often that we do multiple Debian revisions of most upstream version anyway, so people will only feel that if they upgrade directly from backports to a different release of the same version. Bastian -- Fascinating, a totally parochial attitude. -- Spock, "Metamorphosis", stardate 3219.8
Re: Debian Kernel version and ABI in respect of #1040901
Hi On Thu, Jul 13, 2023 at 11:28:31PM +0300, Adrian Bunk wrote: > On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote: > > ### NMU > > Can be easily added back by adding "bX" or so to the ABI. > That would be confusing, bX is naming convention for binNMUs in Debian > revisions. Right. > > ### BinNMU > > > > Is impossible to support. The version change requires changes in the > > names of the created packages. > >... > It should only be impossible to make them co-installable, > or what other reason requires a rename? The contents are incompatible. We can of course completely remove the ability to load modules after a kernel upgrade and then install everything into "linux-image-amd64". Bastian -- Deflector shields just came on, Captain.
Re: Debian Kernel version and ABI in respect of #1040901
On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote: [...] > ## Proposed behaviour > > This tries to make sure everything apart from experimental gets new > names and ABI on every upload. > > * experimental: > Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4 > Keep ABI 6.1.0-0-arm64 [...] Why would that still be acceptable in experimental? Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. signature.asc Description: This is a digitally signed message part
Re: Debian Kernel version and ABI in respect of #1040901
On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote: >... > ### NMU > > Can be easily added back by adding "bX" or so to the ABI. That would be confusing, bX is naming convention for binNMUs in Debian revisions. > ### BinNMU > > Is impossible to support. The version change requires changes in the > names of the created packages. >... It should only be impossible to make them co-installable, or what other reason requires a rename? cu Adrian
Debian Kernel version and ABI in respect of #1040901
Hi folks You might have heard that the masters of Linux Secure Boot, aka shim reviewers, have spoken. They have told us that our way of handling kernel modules is not longer acceptable. For some context see #1040901. This means for us that we have to make sure that kernel and modules can't be mixed between different builds. If we want to continue with the current behaviour, where you can keep old kernels usable, we have to rename packages and kernel internal ABI on every upload. This is the first version of a proposal that should work. But it also ignores some Debian and release policy points to avoid some problematic behaviour. For example it should not possible for package names to grow unrestricted. Please share your thoughts or if we have a better solution overall. Regards, Bastian ## Current behaviour Currently in use are the following types: * experimental: Version 6.1~rc2-3~exp4, 6.1.2-3~exp4 ABI 6.1.0-0-arm64 * unstable/testing/stable: Version 6.1.2-3 ABI 6.1.0-1-arm64 * security/LTS: Version 6.1.2-3~deb12u4 ABI 6.1.0-1-arm64 * backports: Version 6.1.2-3~bpo12+4 ABI 6.1.0-0.bpo.1-arm64 But our version check allows allow more variants, including NMU, BinNMU, local versions, +bpo, ~deb11u1~deb10u1. ## Proposed behaviour This tries to make sure everything apart from experimental gets new names and ABI on every upload. * experimental: Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4 Keep ABI 6.1.0-0-arm64 * unstable/testing/stable: Keep version 6.1.2-3 ABI 6.1.2-3-arm64 * security: Use same version ranges as stable, makes it impossible to do stable and security with the same minor. Version 6.1.2-3 ABI 6.1.2-3-arm64 * backports: Keep version 6.1.2-3~bpo12+4 ABI 6.1.2-3.bpo12.4-arm64 * LTS: Version 6.1.2-3~deb12u4 ABI 6.1.2-3.deb12.4-arm64 * Everything else: Not for Debian archive. Keep version ABI 6.1.2-local ## Removed feature for now ### NMU Can be easily added back by adding "bX" or so to the ABI. ### BinNMU Is impossible to support. The version change requires changes in the names of the created packages. ### Release team prefix The release team mandated debXuY suffix is not used for any stable/security or similar release. Only the LTS one for now uses that. This makes sure we never accrue more then one such suffix in any version, to make sure it does not grow unlimited. New stable uploads always try to gather new upstream minor releases, so we should be safe. -- I have never understood the female capacity to avoid a direct answer to any question. -- Spock, "This Side of Paradise", stardate 3417.3
