Re: [RFC] Reorganizing Linux packages
On Mon, Sep 08, 2025 at 10:11:40PM +0200, Ben Hutchings wrote:
> On Sat, 2025-08-30 at 13:00 +0200, Bastian Blank wrote:
> > The goals are:
> > - Remove hard dependency between headers and (bootable) image
> I generally agree with these goals, but I would like to see how this is
> done.
This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1661
> > ### 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).
This would be a two or three packages split, way less likely to break.
And for udebs we really should work with d-i and see if we can reduce
the package count by merging stuff. We also are way less constraint
with size then ten years ago.
> > ### Replace extra cloud build with stripped down variant
> > 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.
Well, at least we can see if it will boot in the configurations we
actually can test. The cloud config as currently used is officially not
supported with anything we can just run, however sure it works.
With a CI config, we clearly tell that this config is only for tests and
nothing else. And we currently have time problems with out CI builds
anyway.
> 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.
Yes, Modules.symvers would contain modules that can't be directly used.
How do other distributions handle that?
> > ## Side effects
> > - Images will get uninstallable until signed packages are available by default
> Can you expand on this?
We will have a cross-source equal dependency between linux and
linux-signed for linux-image always.
linux-base-bla, linux-modules-bla comes from linux.
linux-image-bla comes from linux-signed and depends on linux-base-bla.
Bastian
--
Warp 7 -- It's a law we can live with.
Reply to: