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-static-libraries 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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
