On Tue, 16 May 2023 at 04:22, Russ Allbery <r...@debian.org> wrote: > Luca Boccassi <bl...@debian.org> writes: > > On Mon, 15 May 2023 at 16:18, Russ Allbery <r...@debian.org> wrote: > > >> 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). > > > Is that really the case? Let's test that hypothesis: > > I think you may have not read my whole message before replying, and also > please assume that I know really basic facts about glibc compatibility and > am not referring to that. > > I said "of a similar vintage" (farther down in my message) because of > course we all know that binaries built against newer versions of glibc > don't run on systems with older versions of glibc (and likewise for shared > libraries in general and thus libselinux), and you tested a Debian > unstable package on an Ubuntu system from 2020. This says nothing > interesting and has nothing to do with my point.
It does say something interesting. When we started, the assertion was that packages not relying on the symlink being present was fundamental for portability and cross-compatibility. Then, it shrinked to portability and cross-compatibility of a subset of packages. Now it further shrank to portability and cross-compatibility of a subset of packages of a subset of vintages. Why is the requirement that libselinux and glibc are not too recent fine to have on coreutils, but the requirement that there's a symlink is out of the question? If anything, the latter is trivial to add, so the formers should feel more "disruptive" and game-breaking, no? > > Whoops. Does this make coreutils rc-buggy now? ;-) > > You are the only person who is talking about RC bugs. The bar here is not > "prove to me that this is RC buggy," the bar is "you have to prove to a > bunch of Debian core maintainers that they should break the ABI in their > packages" (not to mention the additional small but permanent build > complexity). Demanding they prove to you that it's a bad idea is not how > this works. It's a tongue-in-cheek comment, I had hoped the emojii would give that away. > The point of standards like an ABI is that a bunch of entirely unrelated > people who never talk to each other and never look at each other's > software are allowed to rely on them and assume no one else will break > them. This is how free software scales; without invariants that everyone > can rely on without having to explain how they're relying on them, it is > much more difficult to get an ecosystem to work together. We don't just > break things because they don't seem important; the space of people who > may be relying on this standard is unknowable, which is the entire point. > Opening those boxes is really expensive (in time, planning, communication, > debugging, and yes, compatibility) and we should only do it when it > really, really matters. But does it really work, or do we just hope it does? I personally see a great deal of signals that say it doesn't. For one, in 2023, "build one binary and run it everywhere" doesn't really seem to me to be the principal choice in terms of portability. It might have been once, and there might be a number of relevant use cases still, but it seems to me the industry has largely gone in a very different direction nowadays. > > It did look like a veto to me. More importantly, isn't relying on > > passersby to spot alleged harmful changes dangerous, especially for > > undocumented, uncodified and untested use cases, like unspecified and > > vague cross-compatibility requirements? > > I'm honestly boggled. This is a thread on debian-devel, which is > literally how we do architecture vetting in this project. > > I absolutely do not think that we can write down everything of importance > in designing a distribution so that we don't have to have conversations > with other people in the project who have deep expertise when considering > a significant architectural change like changing the PT_INTERP path of > core binaries. Not everything of course, but wouldn't it be worth it to specify core items such as cross-compatibility requirements? Not in terms of implementation details, but in terms of what the goals and the minimum expectations are. There are obviously some, and they are obviously of great importance to many, and yet to me it feels like they shift every time I ask a different question. > >> 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. > > > I don't believe I've done any yelling here. > > I'm using yelling pretty broadly and probably rather inaccurately here. > Maybe a better way of putting it is that Steve was yelling and you didn't > appear to be listening or understanding why he was yelling and were > responding in ways that were guaranteed to make him yell more. > > You *are* coming across as kind of contemptuous of other people's > arguments, but then it's entirely possible that I am as well, so I'm > trying to ignore it. I am sorry it comes across that way, if I am trying to poke holes into use cases it's because I am trying to understand them, where they come from, and what their implications are for my work, there is no contempt involved, I assure you. If you find this discussion hurtful we can stop it. > > What if "setting the parking brake" is not enough, as the wheels are > > already off and rolling downhill, as shown above, because while > > everybody was looking at the parking brakes lever somebody ran off with > > the bolts that kept the wheels attached? Why is it worth worrying about > > compatibility with something that is already not compatible, and it's > > not expected to be compatible for almost all other aspects? > > You can certainly decide to try to make the argument that ABI > compatibility between Linux distributions is a lost cause and we should > give up and not care about it any more. That is a valid architectural > argument. (To be clear, I don't think this is the argument you've been > making up to this point, which is about a very limited ABI break in > specific packages to achieve a specific purpose.) I don't agree with that > argument, which doubtless doesn't come as a surprise, and your > justifications for why you don't think it's important are not persuasive > to me. > > Obviously my arguments are also not persuasive to you, and that's fine, > but hopefully you at least understand *what* the arguments are. I realize > that you really want to have an argument about specific known and > enumerable problems, and part of what I'm trying to get across is that you > are not going to get that. I am, in fact, actively opposed to making that > the only criteria for decision-making in Debian. Things like standards > compatibility, complexity hiding, long-term sustainability, long-term > maintenance complexity, anticipated edge cases, previous invariants, and > subjective risk are, to me, vitally important to a good architectural > process, often *more* important than specific enumerated flaws. I think it's fine to talk about first principles, in the right context. When talking about a very specific, very practical, very "tangible" detail like a path listing, to me it seems quite important to contextualize it to how/if it actually works in the real world. In the hyperuranium lives this beautiful idea that you can take a coreutils package built for Debian, unpack on another distro and, thanks to that one path listing, it just works. Beautiful! Except, er, it doesn't actually work in tons of cases. I mean, there must be a reason why literally billions of dollars and thousands of engineering-years have been poured into creating entire new infrastructures and ecosystems to actually build really portable applications, such as containers/flatpak/snaps/appimage/etc, no? For me, this context seems quite important to keep in mind, when delving into details. Software is many things, but a work of art to be appreciated just for being is not one of them (especially mine!), without functional utility most of the appeal goes. But if you prefer to focus on first principles, that's great! I've been asking this a lot: is cross-distribution harmonization a core requirement? Is it important enough to trump other goals and distro-local benefits? If so, isn't it worth to discuss it and then pencil it down? Kind regards, Luca Boccassi
