Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
Scott Kitterman
ubuntu at kitterman.com
Tue Aug 19 22:58:39 BST 2008
On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <mathiaz at ubuntu.com> 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
More information about the Ubuntu-motu
mailing list