In theory, it should be reasonable for a stable linux distro release to lock in stable gem versions that have been tested at the same level as the distro.

It's just the case that for Ruby the library ecosystem is being developed at a fast enough pace that few want to settle for gem versions that are 6-18 months old.

If the debian ecosystem was actually functioning as designed, someone would create a trusted apt repo with well tested updates that would perhaps be 3 months behind bleeding edge. This would likely be adequate for most ruby projects. It's my impression that the python community is better supported in the debian world.

Suggestion: the gem utility should be able to generate deb and rpm packages with proper version numbers, and the utility should also have a setting to "pull from distro repository" to allow things like bundler to be compatible with apt... this would allow/entail letting multiple gem versions live side by side, which would likely seem like a distro-smell to many sysadmins (though it isn't one).

In my experience the Debian problem goes way beyond not having the most recent gems; they broke Rubygems, so that things like Bundler don't work.

No matter what they thought was reasonable, they should have just left gems alone.

How did they break it? If you don't install ruby from apt, you won't get the debian version of ruby or rubygems, and nothing is broken.

Is it reasonable to expect the apt version of ruby + rubygems to play nicely with an arbitrary compiled version that is installed in PATH? It would be nice, but few packages work this way.

It's reasonable to expect that apt's Ruby/Rubygems works with Bundler in the same sense as it's reasonable to expect that apt's Apache will set the right MIME type for a ".html" file, and not set it "application/binary" by default because some configuration file some Debian person thinks should exist isn't there.

Put more simply: if they can't package a rubygems that actually works with the rubygems ecosystem, they should not package rubygems at all.

I think that's a reasonable point.

> How did they break it?

After their changes, the tool does not function as it was originally intended. Certain sections of the official rubygems documentation give instructions that do not work with the Debian version of rubygems. How is that not broken? In what way did they not break it?

I understand and admire Debian's commitment to cleanly built, working software. Within that context I also understand that rubygems is a big, scary unknown. That said, if the only way to solve the problem is to hack up rubygems until it no longer works as intended, the only real answer is to not ship rubygems within Debian. It just flat out has to be left in "here be dragons" land. As things are right now people just get pissed off that Ruby isn't working correctly under Debian, then they have to go play with dragons anyways.