On Wed, Jan 22, 2025 at 01:32:55PM +0000, Daniel P. Berrangé wrote: > On Wed, Jan 22, 2025 at 01:27:09PM +0100, Fabio Valentini wrote: > > On Wed, Jan 22, 2025 at 10:52 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > > > An increasingly large part of the ecosystem is working and deploying > > > a way that Fedora (and derivative distros) are relegated to only > > > delivering what's illustrated as Ring 1. This is especially the case > > > in the CoreOS/SilverBlue spins, but we see it in traditional installs > > > too which only install enough of Fedora to bootstrap the outside > > > world. Meanwhile ring 2 is the space filled by either language specific > > > tools (pip, cargo, rubygems, etc), and some docker container images, > > > while ring 3 is the space filled by Flatpaks and further docker > > > container images. Fedora meanwhile continues trying to package and > > > deliver everything the same way as we did for decades, as if this > > > shift were not happening. > > > > This kind of misses the point that Fedora packages do provide (in my > > opinion) quite a lot of value on top of most language-specific package > > package managers. > > > > pip is a little bit more advanced than other tools here, but `go > > install` and `cargo install` are extremely simplistic. > > They download sources, build locally, and can only install executables > > into the user's $PATH, nothing else. > > > > The RPM package provides: > > - no need to download sources and compile everything locally > > (including installation of the Rust compiler, C compiler, > > development headers for C libraries that are used, etc.) > > - system-wide installation integrated with the package manager > > - integrated installation of shell completions, manual pages, etc. > > > > Most importantly, `cargo install` has *no* update mechanism (other > > than running `cargo install` again), and has *no* mechanism at all for > > shipping security updates to users. > > What you say all makes sense in terms of the leaf node (application) > packages, where RPM or containers add value as a delivery format. > > When it comes to handling the dependancies that make up an application > though, it is not so clear cut that packaging each dep as an RPM is > inherantly better than bundling them with the application, supported by > the native package tools where appropriate during packaging of the app, > as well as during the day-to-day development work. It is quite clear. The general benefit is that by splitting the deps into rpms, we divide the (increasingly large) dependency trees into "chunks", which allows the work to be split between multiple maintainers, and for the components to be individually updated, patched, described, and tested. The split into separate packages also provides encapsulation, we normally interact with the external projects through a limited API. And we deal with each "chunk" once, so when patches or fixes are required, we don't do it over and over. And finally, in the deployment, we have single versions of things, on disk and in memory. The biggest insurmountable problem with the native language tools is that they work tolerably well for that language, but fall flat when we need to integrate with external projects. We've seen that happen over and over in the Python ecosystem. We have a nice new shiny tool that quickly builds Python packages, then users request support for C and C++ extensions, then Fortran and Rust extensions. This isn't too tough, but when those extensions want to link against external libraries, the "native language tool" needs to learn how to compile libraries. Heck, it even needs to detect if libraries are available on the system and do other ./configure-like tasks. And sadly, this is usually the moment where those "language specific tools" are not nice and shiny anymore, and the job that they do is actually inferior to specialized tools. And then we get to all the other shortcomings of "native tools". Fabio mentioed some for 'cargo' in the sibling email. No clean upgrades, no clean uninstalls, no querying. I don't want to argue that this approach is always the right one. I'm completely willing to accept that Golang has nasty little packages with no good versioning and and vendoring is the only option… But let's keep this contagion contained. Zbyszek P.S. You also mentioned day-to-day development. This is a special case of Mathew Miller's too-fast-too-slow problem. The one thing I have open in my editor now is foremost in my mind and I'm happy to use some custom command to build it, and maybe I'll even do various semi-reliable things to speed up development or to make debugging easier. But as soon as I move onto something else, I want to fall back to the packaged version, reliably built and updated without me having to spend any thought on this or any other of the thousands and thousands of packages I use use every day. -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
