Hacker News Reader

Comment by regularfry | Hacker News Reader

For my money, here's what needs to happen (from a Ruby perspective; salt to taste):

1. Debian and Ubuntu stop packaging any Ruby libraries which aren't dependencies of an actual end-user application. If rubygems itself is a library dependency, package it but take away the gem command.

2. Make a public policy saying "If you want to do development, use RVM," and have metapackages with the dependencies for building each RVM ruby (so ruby-dev-mri, ruby-dev-jruby, and so on). Make sure that users know that if they think they need to run "gem install foo", then they need RVM.

It'd be nice for RVM to be able to build system packages, but I don't think it's necessary: there are already systems (nascent, but improving) for converting gems to system packages which handle dependencies nicely.

Is there anything wrong with this picture?

View on HN

RVM is great. But by design it's a solution to compiling software on every machine. This simply doesn't work for lots of sysadmins, especially with lots of machines - it means installing a complete build environment which opens up much more evil.

Well, yes. And that's the effective situation we've got at the moment.

What I'm proposing is a full acknowledgement of that: if you want to live on the bleeding edge, then that should be supported as well as possible, but a very clear delineation should be drawn between the responsibilities of the distribution and those of the developer/sysadmin. RVM does that very cleanly, even if you only use it with the system ruby.

"If rubygems itself is a library dependency, package it but take away the gem command."

Might be better to un-gem any required gems and package them with the app. Then add some code that fakes out any calls in the app to 'gem' or 'rubygems'.

OTOH, rubygems is part of ruby now, so leaving it out might be a problem.

If you bundle one gem with five different apps (as could easily happen with, say, rack), then any security updates to that gem mean that five distro security updates have to get pushed out. That's a lot more work than it needs to be.

As far as calls to the "gem" method go, I have in mind a distro-specific replacement which would check that the right system package is installed instead of the right gem. That would, I think, be handy for packagers.

Having rubygems the library being part of ruby is not something I can see a problem with. Having the gem command available is a problem because it overlaps so much with functionality which should be provided by the distro. That being said, ~/.gem is useful; maybe it should only be neutered for root/sudo.

Reply on news.ycombinator.com