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

[Scott Kitterman]

On Tuesday 19 August 2008 19:56, Mathias Gug wrote:
> On Tue, Aug 19, 2008 at 07:28:02PM -0400, Scott Kitterman wrote:
> > >On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote:
...
> > >> >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.
> >
> > Doesn't that mean they'll get used in place of installed system packages?
>
> See my comment below.
>
> > >> >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.
> >
> > I can see how this doesn't conflict from an installation perspective, but
> > unless I misremember where that is in the path, it will be used in place
> > of anything provided through the distro.  Am I missing something?
>
> Nope - you're right. Binaries installed by the gem command will be used
> in place of binaries provided by packages since /usr/local/bin comes
> first on the PATH.
>
> I assume that users installing gems from source (ie with the gem
> command) want to use the upstream version of the gem rather than the one
> provided by the distro. Using the gem command to install from source can
> be viewed as a local customization of the system by the system
> administrator - thus the usage of /usr/local/bin/.

For a legalistic reading of policy, I think there is nothing wrong with that, 
but how is a typical user of a gem going to know that if they install gem X a 
library used by gem Y, Z, and package A will be replaced/overridden?  As a 
practical matter I think this declares it all to be the sysadmin's problem 
without giving them a way to know what risk they are taking or how to manage 
it.

As I said in an earlier message in the thread it seems very like Windows DLL 
hell.  Hopefully it will mature.  I doubt that as a distro we can do much to 
improve this where it is now.

Scott K