anyway, I had a quick Google. It doesn’t seem that the Gentoo situation is much different (based on this:

• there are gems that don’t have a matching ebuild
• people still use gems direct
• gem still need to compile native code == dependency issues

Things may be a little better on Gentoo, but I wouldn’t say it’s a problem solved.

The title of the post was referring to the disconnect between rubygems and debian, but also the things that gems do that aren’t really suitable in a production setting. Like gem update –system

While you allege there are standards for where things live, I have yet to see anybody give chapter and verse for these things. Nobody has offered patches to “fix” this “problem” that RubyGems is supposed to have. I’ve been complained at enough that I’m not motivated to actively try to fix this problem. Somebody needs to move their fingers from their blogging tool to their editor, check out RubyGems and get working.

Neil Wilson worked with me to improve how RubyGems behaves in Ubuntu and Debian, unfortunately it seems they want to look a gift horse in the mouth.

Neil’s problems getting his work accepted leads me to believe that it doesn’t matter what I do for RubyGems as it will always be wrong in the eyes of Debian and Ubuntu people.

Furthermore, I added a file that any OS-based distribution of RubyGems could add that RubyGems would require (rubygems/defaults/operating_system.rb) in order to improve the update problem. In theory, Debian and Ubuntu should be able to throw their changes into this file in their RubyGems distribution and any time a user manually updates RubyGems it will continue to Just Work. Both JRuby and Rubinius use this feature to add their own customizations.

I’ve just looked, and Debian isn’t using this and I’m not sure why. Perhaps they don’t read my release notes (third new feature).

As far as I know, nobody claiming to be the Debian-RubyGems maintainer has ever posted anything to the mailing list (the maintainer appears to be daigo@debian.org, but there’s no such address subscribed to the mailing list).

There was a time when I cared about making RubyGems not be “broken”, but the more I thought about it the more I found it was a giant political sink-hole.

What mostly annoys me about gems is the split between github and rubyforge. Coming from a perl world where everything is in one place its really annoying.

Having said that gem 1.3 does suck a lot less than 1.1 for dealing with that.

Someone might want to just “upgdate” the system gems – and now the applications break.

Thanks, I’ll rather have my own bundled in and not rely on something that breaks my application because of external influence.

Thats why there are projects like newgem, and hoe, that make the problem even worse – because now to build gem X I also need to have gem “hoe” installed.

The rubygems code is too long to be reliable, thats why it “breaks” every other version. There is just too much of it.

I have long since stopped hoping that the environment where my application will run will have any of the gems the application depends on, and I just put them inline into the application in a vendor/ folder. It’s quite easy to manage with git submodules, and a very short script to build the code (for binary ext) can be part of the installation.

While it is nice to have all the “gems” already installed for you, rubygems makes it a huge PITA. And all kinds of problems creep up, especially when you have more than one version of a gem on the system (yes, that is possible, and stupid, yes.).