On Wed, 17 May 2023 at 01:05, Russ Allbery <r...@debian.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > > 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. > > I think it's pretty clear that I'm totally failing to communicate what I > was getting at with this example and the process is becoming incredibly > frustrating, so I'm going to stop trying here. > > > 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. > > Well, believe what you believe, but I literally do that daily, as does > anyone else who regularly uses software from a Rust or Go ecosystem. Not > a single work day goes by without me running, on some random Ubuntu or Red > Hat or Debian system, binaries that were compiled on some random other > Linux distribution (often I have no idea which one). > > > 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. > > I do think the industry is moving away (well, has already moved away) from > Linux Standards Base pre-compiled C binaries without wrappers like snap or > flatpak, although there are some very notable exceptions, such as Steam's > special use cases explained elsewhere on the thread. I don't believe the > industry is moving away from Go and Rust binaries, so this is, I think, a > more complicated picture than your description indicates.
I know absolutely nothing about Go, and preciously little about Rust, but my understanding from news article and so on was that both of those ecosystems pretty openly avoid "traditional" distributions, in favour of their own self-contained ecosystems. So would that use case be affected, even by an hypothetical and at this point extremely unlikely archive-wide change? Meaning, are those randomly compiled Go/Rust binaries you run for work taken from the Debian archive, or locally/externally/self compiled? I do know we do ship a number of those, although I am very oblivious to the number and nature of that subset. And conversely, if the hypothetical change was just to the essential set, I assume there's no Go/Rust there, right? > > 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 am certainly never going to say no to more maintained documentation. > That would be great. If you're feeling motivated and you're willing to > really listen to what people are saying and accept and understand a lot of > ambiguity and a lot of assumptions that don't match your assumptions, go > for it! > > I personally am not even doing justice to Policy in its existing scope, so > this isn't something I will personally be tackling. Honestly, I should > have spent all of the time I spent on this thread working on Policy > instead. :) Sure, I can add that to my todo list. But I have already two policy items open for review, so certainly won't get to it before those are sorted, hint hint :-) (probably it would have been best not to mention it, lol) > > 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? > > I think some parts of it are a core requirement. It would be very > surprising, and very bad, if we couldn't run Go and Rust binaries built on > another distribution, for example, or if Go or Rust binaries built on > Debian couldn't be used on other distributions, both subject to the normal > constraints of glibc cross-compatibility that everyone building binaries > already knows about. I think other parts of it are not a core > requirement, but still something that is nice to have and that we > shouldn't break without a really good reason. > > I think the specific details of the Linux Standards Base process mostly > didn't turn into something the Linux world wanted to support going > forward, and thus LSB harmonization, while an interesting idea, is no > longer a requirement in general. However, we still follow some pieces of > it that were properly implemented (like the FHS), and while we shouldn't > do that blindly forever (if for no other reason than the FHS is no longer > maintained), it's also valuable to not change that too fast and to only > break compatibility with now-widely-expected file system layout properties > when we have a really good reason. Ideally, we would pick some smaller > subset of the LSB that still matters and agree with other major > distributions on some points of compatibility to, at the very least, help > ease the common problem of needing to administer multiple systems running > different Linux distributions. > > There is no one answer to whether this trumps other goals and distro-local > benefits. It depends on what those benefits are and what those goals are > and how important they are. For Guix, obviously their immutable tree and > hard dependency pinning are more important to them than cross-distro > compatibility, and given their goals, that seems like an entirely > reasonable decision. I would disagree vehemently with that decision for > Debian because Debian is not Guix. Honestly, to me it feels like there are much more interesting, relevant and useful elements of cross-compatibility beyond the binary aspect. But this would be veering very far off topic in an already wild ride of a thread, so I'll avoid mentioning specifics. > In other words, it depends. Sold! @@ -3,6 +3,13 @@ About this manual .. _s1.1: +Requirements +------------ + +It depends. + +.. _s1.2: + Scope ----- Kind regards, Luca Boccassi
