Re: A summary of where I think we are on the technical side of the merged /usr discussion
On Tue, 17 Aug 2021 at 08:08:15 -0600, Sam Hartman wrote:
> In order to build packages that work on a non-usrmerge system, you need
> a build chroot that is not usrmerge.
Well. That's not 100% true: it's more accurate to say that when *some*
source packages are built in a merged-/usr chroot, the resulting binary
packages don't work correctly on a non-merged-/usr system. Most source
packages are fine either way.
Such packages are already violating a Policy "should", because they're
not building reproducibly (and the reproducible-builds infra tests this
for testing and unstable). Ansgar did a survey of this when we were
discussing one of the Technical Committee bugs, and reported that around
80 packages had a bug of this class at the time, which had apparently
dropped to 29 by the time the TC resolution was voted on.
If we want to make buildd chroots merged-/usr any time soon, then I
think we need to say this class of bugs is RC for bookworm.
Re-reading TC resolution #914897, it's possible that these bugs are
*already* RC - at least, that's one possible interpretation of what we
resolved.
However, if we keep the buildd chroots unmerged-/usr in order to avoid
these bugs becoming significant, then, yes, we get the consequences
you described.
This class of bugs applies equally to anything that makes an executable
available at both /bin/foo and /usr/bin/foo, so even if people want to
disregard the two Technical Committee resolutions on the subject of
merged-/usr and look for consensus around symlink farms in the root
filesystem instead, we'll probably still need to make sure bugs of this
class get fixed.
smcv
Reply to: