Matthew Miller wrote:
I fundamentally disagree with Kevin on a deep level about
"entirely
useless", but ... find myself kind of agreeing about the "unpackagable"
part. I mean: clearly we've found a way, but I'm really not sure we're
providing a lot of _value_ in this approach, and I'm also not sure it's as
successful as it could be.
We cannot ship what we cannot package. (Just repackaging upstream blobs is a
no-go, it is explicitly banned by Fedora Packaging Guidelines for good
reasons.)
I'll start with the second: our system for Rust doesn't
really do that.
Developers are going to use cargo and crates.io and we're not going to
convince them that they should do otherwise. (I don't expect anyone
disagrees with this.)
That is one of the issues (along with lack of proper shared library support)
that makes Rust such a painful language: it makes it way too easy for
developers to just add a dependency on some random unpackaged (by
distributions) library with some random license and with random transitive
dependencies.
In a reasonable programming language, you have to think twice before you add
yet another dependency to your project. Tools like cargo make it way too
easy, just add a line and rebuild. So then you end up with a mess like this:
But running `cargo fetch` with a clean cache pulls down *390* crates.
390 dependencies is absolutely insane! No project should ever depend on so
many libraries. This is completely unmaintainable.
*This is what open source winning looks like.*
I remember a Byte magazine article from the 1990 (I just checked!) with
the title "There Is a Silver Bullet: The birth of interchangeable,
reusable software components will bring software into the information
age". [1] This was about the newly-hot idea of Object Oriented
Programming. It was very exciting. But, of course, that vision of the
world did not happen. It turns out proprietary software *can't* do this.
But now we have it! I don't have to reinvent every basic wheel — but even
more than that, I do not have to be an expert in the intricacies of safe
concurrency to write an app that uses that under the hood. That's amazing!
I can do such powerful things from high-level interfaces and trust the
expertise of those who really understand the deep computer science some of
this requires.
Code reuse is great when it makes sense, but this "NPM culture" where
developers happily depend on tons of packages containing trivial one-line
functions is completely insane.
If this is now the essence of "Open Source", then it will ultimately lose.
Proprietary software companies will just be waiting for the next paradigm
shift to lock us into their proprietary ecosystem again. For a large part,
this has already happened with smartphones: you get to choose only between
the Android walled garden (with an open core and lots of proprietary Google
services and (Google and third-party) apps on top) and the iOS walled garden
(which is completely proprietary and closed, even strictly enforcing an App
Store monopoly). We are struggling to escape from that with devices like the
PinePhone. But with development practices relying on an unmaintainable
dependency hell, it will never happen.
I am competent enough to write a silly toy game using Bevy. It might
be
good enough that others will enjoy it. *I am not competent to maintain
many of these dependencies.* I don't even know what most of them DO.
"anyhow"? "bytemuck"?
Welcome to dependency hell!
Worse, many of the Bevy deps are specified with exact versions. Maybe
I
could make the package work with the packaged versions, but ... that
requires deep expertise and even then might lead to unexpected behavior
and has a high chance of putting me at odds with both the engine upstream
and any other games which use it. The packaging guidelines say that I
SHOULD create patches to update to latest versions of dependencies, and
that I should further convince the upstream to take them. Candidly, that
seems like a waste of everone's time.
Hardcoding exact versions of dependencies is one of the worst misfeatures of
those language-specific build tools. It effectively prevents you from fixing
security issues without patching every single application. And of course it
can cause version conflicts between different applications or even between
transitive dependencies within an application. (And, while the former ones
can typically be resolved by shipping both versions of the library, the
latter ones cannot, because you cannot usually link two versions of the same
library into the same program.)
So, going back to Kevin's point: it _does_ feel like this is
unpackagable.
But that's because the barrier to participation seems too high.
No, the answer to upstream shipping an unpackageable mess cannot possibly be
to make it easier to smuggle unpackageable messes into Fedora!
It's not because it's statically-linked binaries [2]
can't or shouldn't
exist in Fedora — that's not one of our core principles!
It is actually one of our Packaging Guidelines that static linking is
discouraged:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
as is bundling libraries:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
(So they can indeed exist, but they definitely SHOULD NOT, the Guidelines
undisputably say so.)
In fact and quite to the contrary, we need to adapt to handle this
amazing
open source success story better.
I fail to see a success story here. I see a failure story. Dependency hell
is not a success.
And, I led with: I appreciate all the work you've all done to
make this
work. That's definitely true — I think it was super-valuable to pilot this
approach. But I think that the Rust ecosystem would be a great place to
pilot a different way. Something lightweight where we cache crates and use
them _directly_ in the build process for _application_ RPMs.
Fabio has already explained very well why that is a horrible idea.
Fedora _needs_ to adapt to stay relevant in the world where every
language
stack has developed a packaging ecosystem which effectively ignores us.
Some of them are missing lessons they could have learned, ah well — but
they also have a lot of nice new ideas we're missing. And, no matter what
we think, we're clearly not going to stop them.
Rust needs to adapt to become relevant in GNU/Linux distributions.
Kevin Kofler