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've been working closely with the Rubygems upstream team and the >> > package is based on the latest source code from their repository which >> > will be released as Rubygems 1.3.0 very shortly. Getting this into >> > Intrepid will mean that it has the very latest Rubygems containing >> > User based gem support, which is required so that Rails' automatic gem >> > installation tasks work correctly. >> >> Does it have any notion of versions yet? > >What are you referring to exactly ? Which use case do you have in mind ?
It's my understanding that gems produces one complete package (gem) with all Ruby libs needed to run the application and that there is no internal notion of versioning. >> If one has two different gems that use the same binaries how does that work? > >Binaries are installed in /usr/local/bin using update-alternatives. The >last installed gems wins. This sounds very like Windows DLL hell. >> 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. >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? >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. Sc -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
