On May 14, 2023 10:48:04 PM MDT, Johannes Schauer Marin Rodrigues <josch@debian.org> wrote:
Hi,
Quoting Steve McIntyre (2023-05-15 02:54:02)
On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
On Sun, 14 May 2023 at 22:37, Josh Triplett <josh@joshtriplett.org> wrote:
The x86-64 ABI is set. Feel free to make the case to the next
architecture designer that their new ABI should have the dynamic linker
in `/usr/lib`. That would *not* have the same downsides, as long as
everyone agrees on a path.
In practice it is not, though. There are other distributions that
change PT_INTERP for their own purposes, they've already been listed
in this thread. And I am still not hearing any concrete, factual use
case that would be impaired by such a change. I'm beginning to
seriously think there aren't any? Is that really the case?
The ABI has been agreed and set down in documentation that *just
about* everybody has been following since its inception. This includes
the most basic set of definitions of what an x86-64 program must look
like, including the interpreter path. If this path is changed, then
*at the most basic level* we'd be making programs that are not valid
by the ABI we've agreed to. This is an *external interface contract*,
not something we should ever consider changing without significant
cross- and inter-project discussion.
Pointing at gentoo or nixos as examples of projects that have decided
to break compatibility doesn't cut it, I'm afraid. They're well known
for changing fundamental things around Linux and (basically) not caring about
interoperability. That attitude is *not* Debian's.
me and Luca have different ideas about how bootstrapping a Debian chroot should
look like and I don't want to make an argument *for* changing PT_INTERP here as
I think that keeping compatibility with others by following ABI is a good thing
and because I think (and hope -- but Helmut is doing that analysis right now)
that the debootstrap problem can be solved in a way I envision without changing
PT_INTERP. But what I do not understand about the argument against Luca's
proposal is:
Obviously, with Luca's proposal, binaries from packages built with a different
dynamic linker path in them would not work on distributions without merged-/usr
symlinks. But if the property of stuff from Debian being able to run on
non-Debian non-merged-/usr systems is an important one, then why was it okay to
have merged-/usr as the default? Because with merged-/usr we already changed
the interface contract for a lot of things because now binaries and libraries
can also be found at other locations than on non-merged-/usr systems. A script
with a /usr/bin/bash shebang built on and for Debian will not work on a system
without the symlinks.
So did we not years ago decide, that the result of the "cross- and
inter-project discussion" is, that everybody is going merged-/usr and that's
why we need it too and that's why it is okay to build a system where binaries
and scripts built for it just may not run on those other systems that do not do
it? With merged-/usr we already *did* "change fundamental things around" for
reasons that are really not clear to me (but which i do not want to discuss
here) and as a result did not "care about interoperability" (with those who do
not also adopt it). In my own Debian work I so far only got extra work because
of merged-/usr and I do not see the benefits (yet) and I was hoping that
"changing fundamental things around Linux and (basically) not caring about
interoperability" was *not* Debian's attitude but alas here we are.
So have we not already burned the bridges to the non-merged-/usr world? Why was
it okay back then to say "we can make this change because all other important
players are doing merged-/usr so we can/have to as well". And now in the
PT_INTERP discussion somehow we care again about those systems? I thought we
already had the "cross- and inter-project discussion" about merged-/usr and
because the result was "yes, go for it" we did it too. But if that is the case,
why do we now care for a subset of the interoperability problems caused by
merged-/usr for systems that don't have it?
As I said, I don't care much about the PT_INTERP value but I don't understand
yet, why this argument about interoperability with non-merged-/usr systems is
working now but it didn't wasn't enough to stop another very fundamental change
in how we build a Linux distro.
Thanks!
cheers, josch