Re: [RFC] Reorganizing Linux packages

Ben Hutchings <[email protected]> Mon, 08 Sep 2025 22:11:40 +0200
Newsgroups	gmane.linux.debian.apt.devel,gmane.linux.debian.devel.kernel
Message-ID	<[email protected]>
On Sat, 2025-08-30 at 13:00 +0200, Bastian Blank wrote:
> [Cc apt maintainers, as this interacts with the versioned package
> support, reply-to kernel maintainers]
> 
> Hi
> 
> This is the plan to re-organize the Linux packages a bit, or maybe a
> lot.
> 
> The goals are:
> - Move packaged files out of `/boot`
> - Replace extra cloud build with stripped down variant of the normal
>   build
> - Prepare for pre-built initramfs and/or UKI
> - Remove hard dependency between headers and (bootable) image

I generally agree with these goals, but I would like to see how this is
done.

[...]
> ### Split modules out of `linux-image` package
> 
> Like the other distributions we should move all the modules into it's own
> package, `linux-modules`.  We can then split this new package further in a
> later change.

Let's not go too far with this.  Managing the current splitting of
modules into udebs already takes significant time (and seems to be
largely unnecessary).

> ### Replace extra cloud build with stripped down variant
> 
> We currently build a special config for cloud environments.  This comes with
> some downsides, like we currently disable DRM and force traditional framebuffer
> drivers.
> 
> This should be replaced with a stripped down version of the normale variant.
> It should specify possitivly which modules and dependencies should be included,
> without need to change the config.
> 
> Currently we use this extra variant for CI builds.  We need to find another way
> to do CI builds without exploiding build times.  Like stripping almost all
> modules from the build.

I like the fact that we do build a real configuration in CI builds, and
I would like to move forward to actually doing some boot testing of
that.  Introducing separate configurations for CI that would never be
used for real feels like a regression.

It seems like this would also result in it being possible to install
linux-{headers,image}-cloud-amd64 and then build an OOT module that
depends on an in-tree module that isn't installed.  Currnently this
problem would be detected at build time.

[...]
> ## Side effects
> 
> - Images will get uninstallable until signed packages are available by default

Can you expand on this?

> - Closes way back to module signing via secure boot key

I don't think that's a concern any more.

> - Unsigned image is not longer installable in a booting configuration
[...]

I think that's fine.  We would need to adjust some scripting, but I see
the current -unsigned packages as an internal detail that only confuses
users.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
signature.asc (application/pgp-signature, 833 B)