I'm dropping the TC bug from this thread, since I don't think it has anything to do with that discussion at this point. I probably should also change the Subject line, but I'm keeping it to make it easier for the people who want to tune out this thread, since I very much doubt they want to tune back in at this point.
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. > 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. 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. > 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. >> 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. > 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
