Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Bastian Blank <waldi@debian.org>]

Hi Ben

On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatible on architectures
> supporting SB (and sometimes incompatible on others due to compiler
> differences or required config changes).

I don't know what you are talking about.  Those two packages have
different versions, so won't contain anything compatible.  It is the
same between 1.2.3-1 vs 1.2.3-2 and 1.2.3-1~bpo13+1 vs 1.2.3-1.

> If someone upgrades from stable + backports to testing, and has OOT
> modules:
> - With DKMS, will a rebuild be triggered if the linux-image package
>   name doesn't change?

The same as with a normal package upgrade, it will rebuilt against the
new version.  It just runs into the same version skew as everything
else.

> - With module-assistant, the new linux-image package will satisfy
>   dependencies of the old modules even though they are incompatible.

No, the two linux-image packages have different versions, so won't
satisfy the dependencies.

> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.                   

Right.  Maybe we need a manual or automatic override for this, we can do
a lot of things.

> > It will not longer be possible to reliably derive the package name from
> > kernel release (see above), as both values are not really related
> > anymore.
> Given all the drawbacks, I don't see the benefit of decoupling package
> names from release strings.
> In the same way that shared library packages must be renamed for every
> backward-incompatible ABI changes, I believe we should keep doing this
> for linux-image packages.

Noted, but I don't see a way to do that.  We can't map versions cleanly
into package names.  We have binNMU, which can't change package names,
so will already in violation of that.  And we already don't do that, see
that huge version ignore list.

Also the ABI in shared libraries is to have two independent updateable
identities.  Nothing is true in case of the kernel, it will just break
on every update of either side, which would be the equivalent of a =
dependency.  So no, shared libraries are not a good comparison.

> > ## Header and tool packages will not longer contain version
> > 
> > The headers packages will not longer include the version.  It won't be
> > reliably possible to derive the package name anyway from the running
> > kernel.
> >
> > This means that only headers of one single version can be available on
> > the system at one time.  This might be a bit inconvinient for dkms, as
> > it can't longer build modules for multiple versions.
> >
> > But we too often have the problem that image and headers go out of sync
> > and then you can't find the correct ones anyway.
> > 
> > Example: linux-headers-cloud-arm64
> 
> This is all downside with no justification given.  Please explain what
> the benefit is.

The current way does not work.  See all the bug reports about
uninstallable packages and what not with dkms.

To build modules against version x, you'll need to install version x of
the headers, not x-1 or x+1.  This currently works most of the time, but
is by far stable.  And if you already have to search for the specific
version, it does not matter if you might have the ability to install
multiple at the same time, the archive will in any case only contain one
version at a time.

IMHO the only way around would be to install image and headers always in
one piece for those who want to build own modules against.  But this
will require further restructuring, as the headers for this then need to
be built from linux-signed-* and arch-any to be without skew.  And
use proper dependencies so everything is installed with the same version
always.

Aka something like that:

Package: linux-image-cloud-arm64
Depends:
 linux-image-1.2.3-cloud-arm64 (= 1.2.3-1)

Package: linux-modules-thirdparty-cloud-arm64
Depends:
 linux-image-1.2.3-cloud-arm64 (= 1.2.3-1),
 linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1),
 linux-headers-1.2.3-cloud-arm64 (= 1.2.3-1)

Package: linux-image-1.2.3-cloud-arm64
Depends: linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1)

Package: linux-headers-1.2.3-cloud-arm64
Depends: linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1)

Package: linux-modules-1.2.3-cloud-arm64

However doesn't building modules currently need the vmlinux as well?
Which would not be fullfiled anyway right now.

> > ## Installer packages will not longer contain too much version
> > 
> > The installer can only ever handle one version of kernel.  Also it got
> > an internal mechanism to detect which packages belong together
> > (the Kernel-Version control entry).  So we have no need to rename them
> > and force a matching change in d-i itself just because a new kernel
> > exists.  So it will not longer contain the full version in the package
> > names if not needed.
> [...]
> 
> In the installer, netboot images break every time the kernel ABI is
> bumped.  I think there's a specific check and error message for this,
> but I'm not exactly sure.  It should be verified that this detection
> will work the way you expect, so that the error message doesn't change
> and create a support burden for the installer team.

There is, I added that error check.  The only change is that
incompatible versions cycle through much more quickly.

> Currently kernel-wedge generates the udeb package names and would need
> to add an option to leave out the version part of the names.  I'm happy
> to work on that once we have an agreement for what to do.

There is currently a bug in the generation of the Kernel-Version control
field, it uses the version from the package name instead of the kernel
release.

Bastian

-- 
To live is always desirable.
		-- Eleen the Capellan, "Friday's Child", stardate 3498.9