On Wed, Jan 24, 2024 at 01:01:34PM +0000, Luca Boccassi wrote: > On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues > <jo...@debian.org> wrote: > > > > Hi, > > > > Quoting Luca Boccassi (2024-01-24 12:59:38) > > > There's always option B: recognize that the Rust/Go ecosystems are not > > > designed to be compatible with the Linux distributions model, and are > > > instead > > > designed to be as convenient as possible for a _single_ application > > > developer > > > and its users - at the detriment of everybody else - and for large > > > corporations that ship a handful of applications with swathes of engineers > > > that can manage the churn, and it is not made nor intended to scale to > > > ~60k > > > packages or whatever number we have today in unstable. And simply stop > > > attempting to merge these two incompatible ecosystems against their will, > > > at > > > the very least until and unless they reach feature and stability parity > > > with > > > the C/C++ ecosystems - stable API/ABI and dynamic linking by default. > > > > > > There are many ways to ship applications today that are much better > > > suited for these models, like Flatpak, where the maintenance burden is > > > shifted onto those who choose to opt in to such ecosystems. > > > > how does that work for those applications that require rust, go and friends? > > Are you proposing that everything that needs them should be be distributed > > by a > > flatpak or similar mechanism instead? > > Those applications are not shipped in the distribution. If somebody > wants to use them, they'll have to figure it out, just like for > everything else that is not shipped in the distribution, which is > already a subset of all available software in the world. > > > Just a few days ago I tried building mesa from experimental (otherwise there > > are severe graphics glitches on my platform) on bookworm and everything > > worked > > except its rust build dependencies. I had no luck trying to backport those > > parts of rust that I needed and even if it had worked, it would've meant > > backporting dozens of rust packages just to have a backport of mesa. It > > seemed > > way simpler to just disable the mesa component that requires rust and call > > it a > > day. But that probably doesn't work for all applications and maybe sometimes > > the component written in rust is actually what you want. And in case of > > mesa, a > > flatpak of it probably would also not've helped as that would've meant that > > I > > need to run everything that I want to run with a more modern mesa based on > > that > > flatpak, right? > > > > So how is option B a solution in practice? > > You have found first-hand the exact problem with this ecosystem. Now > try to imagine doing that for 30k packages, all vendoring, pinning and > static linking against each other at different, incompatible versions. > Again, the solution in practice is to simply disable or patch out > those components, and if somebody needs them, they can complain to > upstream and ask them for a solution, if there is one. If there isn't, > though luck. And yes, that is not great - but neither are all other > options, so it seems much wiser to me to push responsibility where it > belongs - with the upstreams choosing to use such ecosystems, and the > owner of said ecosystems choosing to make them incompatible with the > distribution model, as they are in the best position to solve the > problem(s) that happen due to their design choices.
This might be a minority, optimistic, rose-tinted-glasses kind of opinion, but I believe that the state of the Rust ecosystem today (I have no experience with the Go one) is quite similar to what Perl and Python modules were 25, 20, bah, even 15 years ago. Gradually, with time, the module authors realized that if they wanted people to use their modules, they would eventually have to settle on a stable API and only make incompatible changes very rarely. With time, with this realization trickling up and down across the most used libraries, things slowly start to get better. Yes, even now there are what can only be called "transitions" in the Perl and Python Debian packaging - some often-used module makes an incompatible change and the packagers need to wait until all the other packaged modules have either caught up or it has somehow been proven through testing that some of the dependent modules are not really affected by the incompatible change. In my experience, nowadays this happens much, much more rarely than 10 or 15 years ago. I have no idea how long it will take the Rust ecosystem to realize that. I know that some of the most widely used modules have already done that, some of them have been at the same 0.x.* or even 1.* version for years (yes, really, years). So... here's hoping. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
