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.
Attachment:
signature.asc
Description: This is a digitally signed message part