Hi,

And sorry for the delay…

Ben Hutchings <[email protected]> (2026-06-12):
> On Fri, 2026-06-05 at 12:27 +0200, Ben Hutchings wrote:
> [...]
> > I have *not* tested whether having these additional udebs available
> > will affect the inclusion of packages in official installer builds
> > for the final point release.  To test this, would it be sufficient
> > to put them in localudebs/, or should I put them in a local APT
> > archive and add a sources.list.udeb.local pointing at them?
> 
> I tested a netinst build with the additional udebs available in
> localudebs/, and as intended and expected they were *not* included.

Right, things would only be pulled from there if there were listed in
package lists.

> But I also wanted to test "CD" builds.  Unfortunately setting LOCAL +
> LOCALDEBS + UPDATE_LOCAL changes the behaviour of various scripts in
> debian-cd so all the extra packages get copied into a separate directory
> in the image.  To test the behaviour of an official build with new
> packages present, it appears that I would need to somehow merge the new
> packages into my mirror.  And I can't see how to do that.

Right, using those variables is tricky, can be useful to get local tests
that are somewhat useful to make progress with debian-cd features/fixes,
but depending on the exact topic it can create enough divergences from
official builds that one can't draw accurate conclusions.

> Unless someone can help me to create that merged archive, I'm afraid I
> will have to test this after linux-6.12 is in bookworm-proposed-updates,
> and fix any breakage then.

I have a local amd64 mirror handy, I can probably merge things manually
there to give this a try, and let ftpsync clean things up afterwards.

Reading your initial mail again, it looks to me we're looking at having
extra udebs getting included into the official images, since all udebs
are included by default. Unless their size is noticeable, they shouldn't
push packages out of the first image; if they do, and/or if we don't
want those udebs included, we could just exclude them at the debian-cd
level (see data/*/exclude-udebs).

If we want to be safe, patching debian-cd to exclude them in advance
would make sense to me, advising the images team to double check what
happens on release day.


Cheers,
-- 
Cyril Brulebois ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply via email to