On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote: > On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <[EMAIL PROTECTED]> 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 > >> > (https://bugs.edge.launchpad.net/ubuntu/+bug/145267). > >> > >
> >> 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 http://www.ubuntu.com -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
