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.
