Re: Trixie

Cyril Brulebois <[email protected]> Thu, 26 Dec 2024 02:58:10 +0100

Newsgroups	gmane.linux.debian.devel.cd
Organization	Debian
Message-ID	<[email protected]>

Cyril Brulebois <[email protected]> (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 ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (application/pgp-signature, 833 B)