Cyril Brulebois <kibi@debian.org> writes: > Cyril Brulebois <kibi@debian.org> (2024-12-26): >> The problem on the debian-cd side is different. It uses a d-i daily >> build that it has no control over, which might need matching udebs >> that bad luck went away between the d-i build and the debian-cd one. > > Seeing how (at least these past few days, weeks, months, or so) udebs > have piled up in the archive, it's probably more a matter of making sure > to include the right set of udebs onto the image, instead of picking > whatever is the latest. > > From a cursory look at the context of the recent bugfix (which is > deeff0673833ae6ae97e3f7f96419254763f1d0f in debian-cd), debian-cd picks > whatever is the highest version, regardless of what's actually used by > d-i. In other words that traded a constant problem (not having enough > space to include linux-image debs) with a transient one (the wrong set > of udebs might get picked). > > Provided there's no immediate decruft in the archive (the current number > of udebs for past kernels suggests that's not happening), it should just > be a matter of: > 1. picking the right set (beware of archs with several flavours) based > on info collected from the d-i build; > 2. bailing out if that version can't be found. > > (1) would fix the issue, and only fail to work if and when the decruft > becomes super aggressive; (2) would avoid building an image that cannot > work if and when that happens. Oh, that seems like a good route forward. I'll try to fit some experimentation with that in-between family/holiday commitments. Thanks for the ideas :-) Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
Attachment:
signature.asc
Description: PGP signature