Luca Boccassi <> writes:
> On Mon, 15 May 2023 at 02:26, Russ Allbery <> wrote:

>> (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.

Ah, okay, I'm happy to agree with that point: you can violate the ABI and
continue to be a working distribution.  (There are a lot of parts of the
ABI that if you violated them you would not have a working distribution,
but this is not one of them so far as I can tell.)

> 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.

I think we're saying the same thing but quibbling over phrasing.  I'd put
that as saying that it's fine for the binaries of certain core Debian
packages to be incompatible with the ABI because they're not intended to
be used outside of Debian.  (In other words, I'm talking about
incompatibility as a concrete, testable property of a binary, and I think
you're talking about incompatibility as a more abstract concept of a

> No aggression intended whatsoever, sorry if it appeared that way. I am
> trying to understand what the rules are.

Well, the rule that I'd ideally set is don't break the ABI, even if it's
not obvious why breaking the ABI is a bad idea or you can't see any bad
consequences that could come from it, unless the reason for breaking the
ABI is absolutely central to the mission and purpose of Debian.

That said, it's not like we've never shipped a binary in Debian with a
different PT_INTERP.  (I vaguely remember that some programming language
uses PT_INTERP tricks for some sort of private binary scheme?  Objective
CAML or something?  I ran across it once years ago and can't remember the
details.  Also, IIRC klibc does some sort of PT_INTERP trick in some
situations that I don't remember the details of, although I don't think it
does that with general binaries.)  So I do see your point that you would
prefer the rule to be more pragmatic than that.

My counterargument is that this proposal seems to mostly be about avoiding
having to create a symlink at a critical point in the bootstrap process,
and while it's tricky to get the timing right (and therefore kind of
annoying), the resulting usable system has to have that symlink anyway (I
think there's no disagreement about that).  Not following the ABI for core
binaries seems like a scary change with unknown consquences to a bunch of
core packages to solve what looks like a relatively minor (if admittedly
annoying!) problem.

Note that the target of PT_INTERP on Debian is *already* a symlink, to
/lib/x86_64-linux-gnu/ which was the multiarch path
that we actually want to use.  We're already ensuring compatibility with a
symlink and I think we should just keep doing that and not venture into
these waters.

>> 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.

I'm not sure why you think this is true and it makes me wonder if maybe my
intuition about cross-distribution compatibility is wrong.  I would expect
to be able to copy, say, most (all?) binaries from coreutils from a Debian
system to some other distribution and run it (and that's exactly the sort
of binary that is useful in this kind of cross-distribution rescue case).
Is this not true today?  What breaks?

Note that we're not talking about complicated packages with lots of
runtime like, say, Emacs.  As I understand it your proposal wouldn't
change PT_INTERP for that binary anyway.  We're presumably talking about
the kind of binaries that you need to bootstrap a minimal system, so
packages like coreutils or bash.  And I would indeed expect those binaries
to be generally portable, as long as the same critical shared libraries
are available on other systems (in this case, PCRE2 and ncurses).

> Why are the existing incompatibilities allowed, and this isn't?

Because it breaks the ABI.  I know you don't find that answer satisfying,
but that really is my answer.

> 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.

Right, this is our point of fundamental disagreement.

> 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?

Well, the concrete answer here is that in order to make this change,
you're going to have to convince a bunch of Debian core package
maintainers to go along with this change and build their binaries in ways
that break the ABI.  I believe at least some of them are going to have the
same reaction that Steve and I had, and will require a lot of convincing.

> 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)?

I really would be surprised if coreutils didn't work, but maybe I'm wrong?
It does appear to generally have a PCRE2 requirement, but I would expect a
compatible PCRE2 in other distributions of a similar vintage.

> 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?

Policy indeed probably doesn't say that you have to follow the Linux ABI
for normal binaries that aren't doing weird language-ecosystem-specific
things, but that's partly because it's so foundational and so automatic in
normal uses of compilers and linkers that I don't think we ever had any
reason to put it into Policy.  It certainly didn't occur to me that anyone
would want to change the ABI for a subset of Debian packages.

Also, I thought you didn't care about Sacred Ancient Texts like Policy.  :)

> 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?

Yes, I absolutely want to be in a place where anyone can raise any reason
that matters to them in public discussion as a reason not to do something
they think would be harmful!  This is the whole point of working
collaboratively together on a shared endeavor.  Everyone gets a say!  That
doesn't mean they get a *veto*, but they get a *say*, and that say is
weighted by how much perceived expertise they have and how directly the
plan affects their work in Debian.

I personally am certainly not expecting to have a veto or even that strong
of a say here.  This doesn't affect any of my packages so far as I can
tell, and I'm far from an expert on the ABI.  I've just been around for
long enough to pick up something by osmosis.  I mostly jumped in because
it felt like you and Steve were just yelling at each other and I thought I
might be able to explain some of where he was coming from in a way that
may make more sense.

> 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.

I would love to get into a situation where Policy is a comprehensive guide
to everything people would like to have rules about in Debian, but I am
also pretty sure that if I quit my day job and made Policy my full-time
job, that would still not be done in ten years.

Distributions are complicated with a lot of moving parts and a lot of
those aren't written down.  This is why we have people with substantial
personal expertise around who can think through novel situations and try
to figure out what the possible options and consequences are.  It's a good

My starting point is that "follow the ABI" is like a safety interlock.
Whenever you park a car on a hill, you set the parking brake.  You don't
try to figure out whether this hill is steep enough to make the car roll,
or do complex geometry calculations to try to figure out where the car
might roll too; you just set the parking brake always.  That makes it a
habit, which has its own valuable properties.  It means that you set the
parking brake in a bunch of places where it's unnecessary to do so in some
objective sense, but who cares, it's a habit, it's automatic.

You're saying "we don't need to set the parking brake here."  You might be
right!  I'm thinking through the negative consequences of that, but I'm
not saying that the specific examples that have come to mind so far are
all that compelling.  My primary argument is that the logic of always
setting the parking brake and not thinking about it is what's compelling,
and you're asking us to give up a point of consistency that acts like a
safety interlock, and I'm saying that makes me very uncomfortable because
it requires we go through this complex process of figuring out what's
might go wrong and we also create an inconsistency at a core level of the
distribution that may have unforseen consequences.  It's a lot easier
mentally and conceptually to just always set the parking brake, and
complexity is the enemy of any large software project.

Russ Allbery (              <>

Reply via email to