Merged-/usr seems to me to have brought great pain with no discernable benefit 
to Debian so far, and I at least have completely lost the thread on what the 
point of doing it was supposed to be.  So, using it as a justification for 
further harm to user and system expectations isn't compelling.


On May 14, 2023 10:48:04 PM MDT, Johannes Schauer Marin Rodrigues 
<> wrote:
>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 <> 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.
>cheers, josch

Reply via email to