Hey Johannes, On Mon, May 15, 2023 at 06:48:04AM +0200, Johannes Schauer Marin Rodrigues wrote: >Quoting Steve McIntyre (2023-05-15 02:54:02) >> >> 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.
Despite the massive upheavals of merged-/usr in *other* ways, it's actually a *minor* change as far as compatibility is concerned here. The runtime linker (aka interpreter) is responsible for resolving symbols and finding needed libraries. So long as *that* bit works OK, then ~everything else should follow OK. This is how it's possible to have things work across distros: binaries don't actually care where the libraries live, or whether they came from rpm or deb packaging, etc. The issue at hand here is that the interpreter path is the most basic thing that matters for this compatibility. Break this and *nothing* can work. >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? This change is absolutely *not* needed to make merged-/usr work; if anybody is claiming that it is, then they are not being 100% honest with us. All the other distros doing merged-/usr have done it without making this change, and it's also been working OK for us so far without this change. Breaking an agreed interface contract like this is axiomatically *wrong* and will hurt us and the rest of the Linux ecosystem. -- Steve McIntyre, Cambridge, UK. st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
