Package: release.debian.org Severity: normal User: [email protected] Usertags: usrmerge
debootstrap in >= buster produces merged-/usr chroots for buster and sid by default. Some packages are misbuilt in such chroots: the only concrete example I have that is currently open is <https://bugs.debian.org/913226> in quilt, in which a package built in a merged-/usr environment will work on merged-/usr systems but won't work (at all) on a non-merged-/usr system. There are almost certainly others; most of them are probably similar to the quilt bug, where the absolute path to an executable on the build system ends up in the package, but to support non-merged-/usr systems we need to canonicalize that path to the version that would work on the non-merged-/usr systems. For instance, src:systemd used to have a similar bug <https://bugs.debian.org/843433>. I've opened sbuild-createchroot bug <https://bugs.debian.org/913228> suggesting that it should create non-merged-/usr chroots to sidestep this for buildd builds, but there are many other ways for maintainers and testers to build binaries. If binary packages in the archive don't work on a non-merged-/usr system, is that a RC bug in the binary packages? For instance, if an uploader of quilt uploaded binaries that had been built on a merged-/usr system without first fixing #913228, would that be RC? (I'm assuming the answer is yes; certainly systemd's #843433 was treated as RC.) Are bugs like #843433 and #913226, in which a package built in a merged-/usr environment won't work in a non-merged-/usr environment, considered to be RC bugs in the *source package* even if the binaries in the archive happen to be OK? See also <https://bugs.debian.org/901473> which proposes that reproducible.debian.org should exercise merged vs. non-merged /usr, as a way to detect this class of bug. smcv
