Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Luca Boccassi <bluca@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: