Luca Boccassi <bl...@debian.org> writes: > That's self-evidently not true, as there are other distributions where > that already happens, it's been already mentioned.
You've mentioned this a couple of times but I don't think I've seen the message where the details were explained. Maybe this was only in your message posted to debian-gcc, which wasn't part of this thread? (It's also possible that I just missed it somewhere.) That message only mentions GUIX, which I don't know very much about, but my recollection (maybe wrong?) is that it's a NIX variant that is doing special tricks to support immutable package trees and roll-forward/roll-back upgrades. I can see why that might be motivation to build incompatible binaries in order to preserve some other invariant they're trying for as the point of their distribution (in particular, I suspect they're pinning binaries to a specific version of the dynamic loader as part of the whole immutable tree strategy). That's a perfectly fine decision in a distribution that's trying to do something very different and is a bit of a science experiment, but I don't think that describes Debian. (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh, major player in Linux distributions, and I'm not sure how much they care about compatibility with anyone else.) > Besides, we are not talking about sacred religious texts - the point is > making things work. If they do, is it _really_ > non-compliant/incompatible? I understand your point in making this argument, but please understand that this sort of willingness to change things if one didn't think they would cause problems didn't work very well, and was part of what led to the development of standardized ABIs in the first place. Those of us who have been around longer than Linux have ABIs have a bit of a strong reaction here (I think this is also what you're seeing from Steve), because we remember the bad old days. I still have compatibility code around to handle the fact that gcc on IRIX miscompiled calls to inet_ntoa because gcc didn't correctly implement the IRIX ABI. People are very bad at judging whether their new idea would be *really* incompatible. This is why these days everyone tries to follow the ABI pretty closely. And in any case, changing PT_INTERP is trivially and obviously incompatible; the binary will simply not run on a system that doesn't have that path. So it's not like we have to carefully judge nuance here. Your argument, so far as I can tell, is basically "but no one will ever want to run those binaries on a non-/usr-merged system anyway," which is basically conceding the incompatibility point since the ABI doesn't require merged /usr. There's also some other history here: Debian is not super-happy with the PT_INTERP because ideally we'd prefer it use a path compatible with our multiarch approach. I believe we raised that and no one had any interest in trying to change anything, so we lived with the limitations that creates. (And I think that was the right decision.) > Thanks, that's the first actual real example mentioned so far. And it's > an interesting one: taking a $random Debian package and using it on a > completely different, non-Debian system. Is that a supported use case? > If so, does that mean that I can go ahead and raise a Severity: serious > bug on any package that doesn't work in such a way? I feel like you're distorting my argument here to try to make some sort of slippery slope argument, and it's coming across as possibly more aggressive than you had intended. The world does not divide neatly into supported and unsupported use cases. There are a lot of things I do to computers that I expect to work in some situations but not in others. That includes, say, having a Debian chroot on some other OS and running binaries from that chroot without going into the chroot. Often that will absolutely not work. Sometimes it will work, and it's convenient that it will work for some obscure recovery situations or other weird one-off use cases. I've also copied files from working systems to broken systems running a different distribution before, and there's a list of caveats as long as my arm, but sometimes it's a quick fix for something. But mostly my reaction is because breaking the ABI is a Really Big Deal. Constructing the Linux ABI and getting the details actually published was a hard-fought, arduous endeavor. I doubt anyone enjoyed it; it's the sort of annoying compatibility work that provides tons of small, subtle benefits and takes a great deal of truly thankless work, and people often don't realize all the tiny ways that it has made the world a better place, or the range of weird compatibility problems that can arise from messing with it. Diverging from it is not something to do lightly, precisely *because* it's often extremely difficult to understand what the effects could be or what might break. While I appreciate how it would make bootstrapping Debian somewhat more convenient in this case, I am unconvinced that this is a good enough reason to undermine one of the foundations of what makes Linux a collective and fairly mutually compatible ecosystem. I realize it's not necessarily obvious that changing PT_INTERP for some binaries is a big deal, in part because it's not even obvious that it's part of the ABI. That's why people who are familiar with the ABI process are jumping in to say "please don't touch that, this is a big deal to us." -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
