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.
Bdale On May 14, 2023 10:48:04 PM MDT, Johannes Schauer Marin Rodrigues <jo...@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 <j...@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
