On Fri, 30 Aug 2024 at 14:25:39 +0200, Santiago Vila wrote:
> My use case is that sometimes I need to know in which date
> some package stopped failing to build in testing because
> an unknown build-dependency finally propagated to testing.

Sure, that makes sense.

> For that to happen I need either:
> 
> (A) Create a usr-merged buildd chroot of bookworm, then upgrade to the
> desired trixie at some unspecified date using snapshot.debian.org.

You are meant to be able to do this with

    debootstrap --merged-usr --variant=buildd bookworm TARGET

possibly wrapped as `sbuild-createchroot --merged-usr ...`. That's meant
to take precedence over the suite- and variant-dependent default behaviour.

Lee reported that this actually didn't always create a merged-/usr chroot,
but josch was unable to reproduce that problem. If you can find a
reproducer for `debootstrap --merged-usr ... bookworm TARGET` creating a
non-merged-/usr chroot at TARGET, that would be a valid bug, in which case
please describe the steps-to-reproduce in more detail (ideally starting
from a throwaway VM of a specified suite).

> (B) Create a non-usr-merged buildd chroot of bookworm, usr-merge it,
> then upgrade to snapshot.debian.org.

I don't think you can do this in any supported way, because a
non-usr-merged bookworm chroot has already opted-out from being validly
upgradable by creating the /etc/unsupported-skip-usrmerge-conversion
flag file. It might be possible to force it by deleting the flag file
and then explicitly installing usrmerge.

> What is the route that I'm supposed to follow?

Either your (A) above, or:

(C) as josch suggested, bootstrap a trixie chroot directly from a former
state of trixie, as available from snapshot.d.o.

(D) start from a bookworm minbase instead of a bookworm buildd chroot
(minbase is merged-/usr by default anyway), and then add build-essential
to it after you upgrade (or even let sbuild install it on-demand).

I would personally go for what josch said, (C) above, because creating
a new chroot/container will be less susceptible to configuration drift
(more reproducible) than upgrading an old chroot/container.

    smcv

Reply via email to