On Mon, 15 May 2023 at 02:26, Russ Allbery <r...@debian.org> wrote: > > 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.)
This is a counter-example to confute the assertion that *everybody* does the same thing, which has been made multiple times. I'm not sure whether it's an experiment or not, I mean if you ask their users/developers I think they'd tell you it's very much production ready, but it is largely irrelevant: it exists, and that's the only reason why it was mentioned, as it shows that it is _possible_ to do that and be a working distribution. Doesn't imply it's automatically desirable, but that was not the intention. > > 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. Not quite: my argument is that binaries from these packages are not intended and not required to be ran on non-Debian systems, so there's no incompatibility introduced in the first place - everything still works where it is supposed to, exactly as it was before. > 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. No aggression intended whatsoever, sorry if it appeared that way. I am trying to understand what the rules are. > 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. Vast, vast majority of binaries from existing packages will already not work out of the box in that use case though. Why are the existing incompatibilities allowed, and this isn't? > 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. I am afraid I am a bit more "pragmatic" than that. I am very interested in what works and what doesn't. Whether it conforms to the letter of the Sacred Ancient Texts... interesting for sure, but secondary. > 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." Let me ask a simple policy question: why do I have to abide to your uncodified, unwritten use case of running a Debian program from a Debian package from outside a Debian chroot on a foreign, unmodified non-Debian system, but you don't have to abide by my uncodified, unwritten use case of running a Debian program on a Debian system with only a Debian /usr? And also, why it is only this change that has to abide to such use case, and the myriad of cases that cannot possibly work in such a setup are given a free pass (I mean I'm pretty sure the only executables that are guaranteed to work as you mention are golang and rustlang, where everything is statically compiled, everything else is already rc-buggy by that standard)? Isn't this the very reason we have a Policy for, so that we don't get to cherry-pick arbitrary use cases to block things we don't like? Are you really sure we want to be in a place where anybody can bring up an out-of-policy use case as a valid reason to block something they don't like? Again, I am fine if we want to say that Debian-specific changes and Debianisms are bad and we cannot do anything that jeopardises interoperability, cross-distribution harmony and mutual compatibility. But let's do that then, and start by writing it down in Policy so that it applies fairly and equally to all cases. Kind regards, Luca Boccassi
