Developer-driven software distribution is a bad idea, which is why I dislike things like Flatpak.

Having distro maintainers involved in the process and installing your software from a free software distribution like Debian or FreeBSD is a much better distribution of power. The packages can be tuned to suit their environment without the developer having to repackage it for every distro, and the distro maintainers can keep out anti-features like telemetry and advertising.

The middleman may seem annoying to developers, but embrace the model and it'll work for you. Landing packages in your favorite distro isn't actually that hard, and the rest of the distros will follow. If you're an end-user who wants to see some software available for your distro, look into packaging and volunteer - it's easy.

@sir as a Ruby app developer, it seems odd to me that I would find Ruby gems in the Fedora package manager. As a Ruby gem maintainer, I wouldn't want to burden distro maintainers every time I release a new version.

Do distro package managers even have features like version pinning? Seems like the repos are stuck with the major version that was out when the distro was released, and in a fast-moving world like web app development, you'd be hamstrung to old gem or npm versions.

@Paul @sir As a (python) developer and a distro maintainer.

In many cases, upgrading a package to a new version isn't a big deal: most of the time is taken by giving a quick review of the code to check that upstream hasn't gone insane :) and then it's a matter of running a few commands to upgrade the package and run tests to check that everything is still working. This is especially true for packages that release relatively often and don't change everything from one release to the next, of course, but many python modules are like that, and I supposed ruby gems are too?

As for version pinning, yes, with stable distributions you are basically pinned to the version available when the distro was released and get no new features, but you do get security fixes (when possible, and when the maintainer gets to know that there is a need for one). On the other hand, it also means that you can be sure that your software will not break until the next *predictable* distribution release.

It is true that as a developer I tend to work on things that are supposed to be maintained for years with minimal developer effort (because there isn't a developer working full-time on them), so I'm especially uncomfortable with the common web approach where you have to either rewrite your code every other month to keep it working with your dependencies or keep it stuck on the version that was out when you wrote the code even if it has known security vulnerabilities.
Follow

@valhalla @sir A quick check of my Fedora 30 install shows there's 1, 250 `rubygem-*` packages available, out of 10,000 on rubygems.org. The current version of the single most popular gem, `rails` in the distro is 5.2.3, and 5.2.4 was released Nov 27. Rails 6 was released back in August. Our main production app has 318 gem dependencies, 137 are available in Fedora 30, and 37 are the version we need.

@Paul @valhalla there is no way that there are 10,000 ruby gems which are worth more than the bytes they take up on disk

@sir @valhalla of course not, including some of mine. But there's more than 1200, since that only covers a third of what's needed for even a comparitively small app like ours

@Paul @valhalla this is more indicative of the ruby community being terrible than of distros being wrong.

@Paul @valhalla @sir I believe that Fedora Ruby is planning to do Rails 6 for Fedora 32, though you could also ask and help make it happen...

Sign in to participate in the conversation
Ruby.social

A Mastodon instance for Rubyists & friends