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. > 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. :) > 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. In other words, it depends. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
