On Fri, 12 May 2023 at 12:08, Steve McIntyre <st...@einval.com> wrote: > > On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: > >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: > >>On Fri, 12 May 2023 at 09:40, Steve McIntyre <st...@einval.com> wrote: > >>> > >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >>> > > >>> >The core issue as I see it is as follows: > >>> > > >>> >- Debian has decided to support only merged-/usr, including possibly > >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > >>> > as the interpreter in binaries. > >>> > >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've > >>> seen. The interpreter must *not* be changed willy-nilly. > >> > >>Nothing's happening 'willy-nilly'. We are discussing a bunch of > >>seemingly crazy options, as in, "what would _actually_ explode if we > >>do this or do that?", on this very d-devel thread. I posted a longer > >>version here some days ago: > >> > >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html > > > >Oh holy fuck. > > > >You're talking about changing ABI by doing this. That *is* utterly > >crazy. No. > > People have asked me to expand on this further... > > I've been involved in defining ABI before, specifically for > armhf. It's not a quick and easy process. It needs buy-in from all > sides to make things work, and people *really* value the > interoperability that it enables. > > The interpreter path is one of the most important parts of the ABI > spec, the bit that makes binaries compatible between all the various > stakeholders: compiler/tools people, distros, software vendors, > etc. Lots of the rest of the details downstream of this can be > changed, and people do this all the time - compare multilib to > multi-arch for example. That all works fine *so long as* the runtime > linker can be located and started OK.
The loader is still available via the old path, so external/third party/local/other software works unchanged. This should negatively only affect our 1st party packages, when running on a non-merged distro. And are _all_ our packages really 100% compatible with other distros at all? Are they even supposed to be? For example, if I download efibootmgr from Bookworm on an Ubuntu Focal machine, when I try to run it, it fails: root@focal:/tmp# wget http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb --2023-05-12 12:46:17-- http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4 Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 27572 (27K) [application/vnd.debian.binary-package] Saving to: 'efibootmgr_17-2_amd64.deb' efibootmgr_17-2_amd64.deb 100%[===============================================>] 26.93K --.-KB/s in 0.04s 2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572] root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm root@focal:/tmp# ./ebm/bin/efibootmgr ./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr) Should I file a severity: serious bug against efibootmgr because it is not interoperable? The answer is obviously not, because it would be absurd to expect a binary compiled against libraries from one distro to "just work" on an entirely different distro. Glibc itself is not forward compatible, and is allowed to add new symbols, that are not present in older versions, and packages are allowed to depend on them. Aren't those also ABI breakages? What about all the libraries that bump soname? What about binaries that rely on newer kernel interfaces, or IPC interfaces? So, what I am asking is, what actual, real difference does it make if, by default (and with an override available for example), packages built on Debian for Debian record the ld path to point to its (actual) location on Debian, via say a compiler spec file that is injected in a deb build? There very likely is some real difference and impact, and I am genuinely and honestly asking what it could be. If nothing else, it's an interesting topic, even if likely nothing comes out of it. > Changing the interpreter path would mean moving to a Debian-specific > ABI, breaking that compatibility. Hand-waving that away with (and I > quote): > > "The vast majority of distros today ship the loader in /usr/lib as > /lib is just a symlink, so it would be interoperable." > > is appalling arrogance. No. You do *not* get to break ABI with that > argument. The point of the ABI spec is that *everybody* follows > it. You don't change it just because you think it'll make your life a > little easier when bootstrapping a system. AFAIK there are at least 3 distros where the default interpreter path is changed to follow distro-specific customizations: Gentoo, Nix, Guix. So evidently, some people *do* get to "break ABI", and not everybody follows it. So why can't we at least _talk_ about it, pros and cons, advantages and problems, without the tones of the discussion needlessly escalating? Kind regards, Luca Boccassi
