On Fri, 12 May 2023 at 15:30, Steve McIntyre <st...@einval.com> wrote: > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > >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. > > So why the hell do you want to break this in the first place? Does a > symlink in the "wrong" place offend you for some reason? For that you > want to change a core assumption in *every single binary* in Debian? > Believe me, I've been here in the past when we made changes in armhf > to accommodate earlier mistakes. That was just for one > architecture. What possible benefit do you see in this change?
As it was mentioned on the list, because it makes bootstrapping self-contained, that's a real and concrete benefit that some developers like Helmut care greatly about, and that's why we are talking about it. To me, it sounds very attractive to have a self-contained and canonicalized distro-wide configuration. If the canonical location where certain files are stored in /usr/bin or /usr/lib, it seems sensible to me to configure Debian software to look for it where we actually put it, while maintaining compatibility for external/local software so that it keeps working. And it is also unclear so far what would outright break - the externally defined ABI in terms of where the loader can be accessed at, would still be respected. Hence why questions are being asked. Nobody's being forced to do anything, this is just a discussion. > >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? > > You're wilfully missing the point, and you know it. I'm trying to determine where the boundary lies. What are the expectations for interoperability? Are all executables expected to be self-contained? Can they rely on external config that is guaranteed to be there on Debian but not elsewhere? Can they rely on external libraries that are guaranteed to be there on Debian but not elsewhere? Can they rely on external symlinks that are guaranteed to be there on Debian but not elsewhere? How is this all defined, and most importantly, what are the actual use cases being covered? > >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. > > I have better things to do than argue about this. I refuse to engage > with this right now. You're talking about breaking things for *no* > discernible benefit that I've seen any discussion about. It is entirely up to you of course, however just saying "things would break" without mentioning what or how does not help to further our understanding of the matter at hand. So far reactions are either one of "what??! weird, but it could actually work!" and "what??! no, because no!". In the absence of somebody explaining "there's use case X that we support as per policy/decision/custom/workflow Y that would break because of Z" I'm finding it very difficult to come to the conclusion that this would actually be problematic, in practice. I am here to be enlightened. > >> 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? > > Again: *why* do you want to do this? For all the value here, should we > also discuss switching to PE-COFF from ELF for our binaries? That's > more commonly used... Actually I'd prefer Mach-O - its native graceful support for optional dependencies (dlopen-like) is really nice! But I digress, and "why" is explained above and in earlier mails. Kind regards, Luca Boccassi
