From: waldi@debian.org 
  
 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. 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)