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
Attachment:
signature.asc
Description: signature