Bug#978636: move to merged-usr-only?
On Mon, 25 Jan 2021 at 14:47:56 -0800, Keith Packard wrote:
> I think that and a transition plan are both key to this project. I
> recently installed Debian from scratch on my HiFive unmatched board and
> it got merged / and /usr.
That ship has already sailed: on #914897 in 2019, before Debian 10, the
TC resolved (unanimously) not to overrule the debootstrap maintainers
after they made merged /usr via aliasing symlinks the default for
new installations. We also voted on what we considered the desired
situation for Debian 11 to be, with option M "middle" (merged /usr not
mandatory, packages can be built on either merged-/usr or non-merged-/usr)
narrowly winning over option H "hard" (packages should only be built in
a merged-/usr environment).
Option W "weak" (packages should only be built in a non-merged-/usr
environment) was defeated by both those options.
> When I built packages on this device, they
> created invalid packages as the shared library dependencies all listed
> /lib instead of /usr/lib.
That shouldn't normally be the case, because shared library dependencies
are done in terms of SONAMEs and package names rather than in terms of
absolute paths (unless you are using RPATHs or RUNPATHs). One of the
variations tested by reproducible-builds.org is that it builds a package
on merged and unmerged /usr, so for any package that is reported to be
reproducible on that infrastructure (there are a lot of them), it
doesn't matter.
This sometimes requires forcing a canonical path via something like
--with-dbus-daemon=/usr/bin/dbus-daemon if the package's configure scripts
would normally detect an absolute path via PATH search and hard-code the
result; in my experience it has normally been executables rather than
libraries that have this problem, because ld.so and shlibs/symbols files
already provide an abstraction layer over the precise physical location
of shared libraries. (#913729 is a typical bug of this class.)
If you are doing lower-level things with libraries, or if you are shipping
libtool .la files or something else that hard-codes the absolute path to
a library, then, yes, this could be a problem with that specific package.
The resolution of #914897 says this is currently considered a bug in
those packages, although if we complete a transition to all supported
Debian systems being merged /usr via aliased directories (layout 1)
then these bugs cease to be bugs.
> Any plan where a transitioning system cannot be used for ongoing Debian
> development seems unworkable to me -- it leaves all active Debian
> developers working on un-transitioned systems, which greatly reduces
> test coverage from people in the best position to help fix things.
The resolution of #914897 was that we consider both transitioned and
un-transitioned systems equally valid for ongoing Debian development, and
any package that builds differently in those circumstances has a bug.
I for one have been continuing to use un-transitioned systems for the
opposite of the reason you are: to give that configuration more test
coverage, because it is *more* likely to exhibit bugs!
The classes of bugs "a file is /usr/bin/x but another package refers to
/bin/x" and "a file is /bin/y but another package refers to /usr/bin/y"
cease to be visible with merged /usr via aliasing, and can only affect
systems where /bin and /usr/bin are distinct. One of the motivations for
merged /usr is to have those classes of avoidable bugs cease to be bugs
at all: if /bin literally *is* /usr/bin on every supported Debian system,
then it doesn't matter which name you use for it, because both paths
are equivalent anyway.
However, if we want that (which I think we do), we need to get there
from here.
> I don't understand the value of 2b; it's functionally similar to layout
> 1, but makes for additional work to create the shadow links, along with
> consuming space for them.
Right. I wanted to describe this layout so that we can be clear
about whether the TC considers it to be a valid implementation of our
recommendation. If we don't, then hopefully we can avoid anyone arguing
that we have mandated this additional work.
smcv
Reply to: