Cyril Brulebois <k...@debian.org> (2024-12-07): > Right now I'm seeing modules for 10 kernel ABIs, that can't help.
After a quick look, I suppose we could extract the kernel ABI(s) from MANIFEST.udebs, matching kernel-image-(.+)\s, and focusing on including only the relevant modules. Most architectures have a single kernel-image but not all of them (mips64el notably). Additionally, given how critical it is to have linux-image-* available on netinst images, I think we should break the build if no such packages make it into those images. We have a lot of #ifdefs in tools/generate_di+k_list and some archs have multiple linux-image-* metapackages pulled, so maybe it'd be safer to check against the intermediary list I mentioned before (list.mid), making sure all linux-image-* packages it contains made it onto the disk? But a simple “no linux-image-* packages at all? surely broken!” heuristic would already be a net win? > I lost count of how critical it is to have firmware-nvidia-graphics > available (I thought it wasn't of much use, and was initially expected > not to move to nff for bookworm, which it did eventually anyway), but > that one alone steals 30+ MB of space before linux-image-*. Leaving that aside for now. > I haven't looked deeper at this point, maybe we have some other kinds of > “duplication” (not sure the t64 thing is over at this point, but I could > imagine how we might pull t64 and pre-t64 libraries until everything is > successfully rebuilt against the t64 ones). Leaving that aside for now. Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
