Re: A summary of where I think we are on the technical side of the merged /usr discussion
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
Reply to: