Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

Mathias Gug mathiaz at
Tue Aug 19 22:46:34 UTC 2008

On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote:
> On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <mathiaz at> wrote:
> >On Tue, Aug 19, 2008 at 03:15:15PM -0400, Scott Kitterman wrote:
> >> On Tuesday 19 August 2008 15:11, Neil Wilson wrote:
> >> 
> >> > Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a
> >> > gem based framework and is completely integrated with the gem package
> >> > manager. In Intrepid I would expect users to continue to use gem to
> >> > install Rails and for that to be feasible we need a Rubygems package
> >> > that works as people expect it to work. I have implemented a patch
> >> > that uses the alternatives system so that we can have gem install
> >> > binaries in the $PATH without gem and apt running into each other and
> >> > without violating Debian policy.  This will close a long standing bug
> >> > (
> >> >

> >> I think the answer (as Python has largely learned and Java is learning) 
> is you 
> >> have to have a system that will let a package use the installed system 
> >> libraries and not try and work around the package management system?
> >
> >What are you referring to by package ?
> >
> >The make a parallel with python, the gem command is similar to 
> easy_install.
> Which we generally patch into submission when we find it.  In Debian/Ubuntu 
> if ezsetup is installing external Python modules it's bug.

Do you mean that ezsetup tries to install debian packages of the python
modules ?

> >Neil's proposal is to improve the gem command (from the libgems-ruby
> >package) so that binaries are installed in /usr/local/bin (thus they're
> >on the default path). If you'd use install gems from the upstream
> >source, binaries would be installed in /usr/bin/. The goal is that gems
> >installed by the gem command don't interfere with ruby libraries and
> >binaries installed by debian packages.
> Do you mean NOT on the default path then?

No. The binaries included in the gem are installed in /usr/local/bin/,
which is on the default PATH.

> >Upstream provided the necessary hooks to do so and Neil used the
> >update-alternatives system to handle multiple version of gems being
> >installed in /usr/local/bin/ rather than /usr/bin/.
> >
> It does sound like progress.  As long as we aren't actually packaing the 
> gems themselves it seems like a reasonable way to go until Ruby Gems grows 
> enough features to support proper integration of gems into the distro 
> package space.

Exactly. Neil's proposal is *not* aimed at integrating gems with the
distro package space but rather improve gem installation from source so
that it doesn't conflict with distro packages. Proper integration is a
long-term goal and we're looking at the Intrepid timeframe. 

The current rubygem package provides a gem command that installs gem
binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH.
Neil's proposal uses update-alternative to make these binaries available
in /usr/loca/bin/ so that they're located in the default PATH. End
users won't have to modify their environment and gems will work OOTB.

Mathias Gug
Ubuntu Developer

More information about the Ubuntu-devel-discuss mailing list