On Thu, 29 Aug 2024 at 14:23:47 +0200, Johannes Schauer Marin Rodrigues wrote: > on bookworm, --merged-usr --variant=buildd is creating a merged-/usr chroot
If that is true, then it is not a bug. The --[no-]merged-usr options have a higher precedence than debootstrap's default behaviour, which is dependent on the suite and variant. For those who are reading the debootstrap source, it's a tristate: the default is MERGED_USR="" which allows automatic selection based on the suite and variant; --merged-usr sets MERGED_USR=yes; and --no-merged-usr sets MERGED_USR=no. The intended truth table *without* --[no-]merged-usr is: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93#note_410656 and this should happen in a fully-updated installation of Debian 11 or later as the host system (Debian 11.0 and 12.0 didn't do this, debootstrap's behaviour was changed in a subsequent point release). When --[no-]merged-usr explicitly selects a layout that is allowed for a particular suite, the expected result is that layout. In particular, for Debian 10, 11 and 12, --no-merged-usr should produce a non-merged-/usr chroot and --merged-usr should produce a merged-/usr chroot, regardless of variant. If --[no-]merged-usr is used to select a layout that is *not* allowed for a particular suite (for example trixie with --no-merged-usr), I would say that the expected result is undefined: it might just fail, or it might produce a non-functional chroot, or it might produce a working chroot that does not have the requested layout. Which of those three possibilities actually happens, and whether there is a warning, is a quality-of-implementation issue. smcv
