Luca Boccassi <bl...@debian.org> writes: > On Mon, 15 May 2023 at 02:26, Russ Allbery <r...@debian.org> 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 distribution.) > 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/ld-linux-x86-64.so.2 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 thing! 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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
