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.
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature