On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote: > 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.
Do we have a dashboard for this so the list of which source packages result in different binary packages depending on whether they are built with a usrmerge vs !usrmerge system? We could look at the reproducible-builds reports, but not all reproducible build failures are caused by the usrmerge/!usrmerge dependency, right? > 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. Agreed; I'd go further, and claim we should get all of these bugs resolved well before the bookworm freeze. On a separate question, at the moment e2fsprogs is installing some files in /sbin and /lib, and other in /usr/sbin and /usr/lib, etc., since historically the goal was to allow systems to boot, and bring up networking, etc., without /usr being mounted. As a result there are some breakout lintain warnings: W: libext2fs-dev: breakout-link usr/lib/x86_64-linux-gnu/libe2p.so -> lib/x86_64-linux-gnu/libe2p.so.2 W: libext2fs-dev: breakout-link usr/lib/x86_64-linux-gnu/libext2fs.so -> lib/x86_64-linux-gnu/libext2fs.so.2 W: ss-dev: breakout-link usr/lib/x86_64-linux-gnu/libss.so -> lib/x86_64-linux-gnu/libss.so.2 Suppose I released a new version of e2fsprogs targetting sid and bookworm which installs everything in /usr/bin, /usr/sbin, /usr/lib, etc, instead of splitting up files in /... and /usr/... * Is this a desirable thing to do now? (Post-bullseye release) * What are the potential risks of doing this now? * Bullseye users might still be assuming that they can boot w/o /usr mounted, is that correct? Hence, for bullseye-backports, I would need to be able to support building e2fsprogs packages which retain some files being installed in /{bin,sbin,lib}, etc., and some in /usr/{bin,sbin,lib}, Apologies for asking these potentially stupid questions, but it would be great if there could be concrete guidelines could be given for package maintainers, not just what is *mandatory* (which would be in policy), and what would be considered *desirable* for a package maintainer who wants to be helpful/proactive and is trying to move the ball forward. - Ted