Bug#913229: release.debian.org: RC status of merged-/usr bugs?
Package: release.debian.org
Severity: normal
User: md@linux.it
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
Reply to: