On Thu, 22 Nov 2007 11:51:54 -0500, Michael Greenly wrote:

>>> Assuming that RubyGems is installed initially through a a distro
>>> package it obviously can't update it's self in place.  I think the
>>> ideal solution here is that RubyGems (through load paths) allowed for
>>> two levels of installation.
>> 
>> Not good, won't work.
>> 
>>> What I mean is if the Debian distributed RubyGems was initially
>>> installed right along side Ruby but an 'update --system' caused it to
>>> install the new version to some none-dpkg controlled directory (that
>>> had load order precedence) everything would mostly work as expected.
>> 
>> Bad. Special case for a mere distro.
>> 
>> 
> 
> My goal is to make using Ruby seem normal from both a Ruby users and
> Debian users perspective.  This means the installation needs to happen
> with system tools; 'apt-get install ruby rubygems' and from there it
> just works like a Ruby user would expect.  Including doing a 'gem update
> --system'
> 
> After thinking about Eklund's response I think I agree that debian's
> 'rubygems' package should be a wrapper script with RubyGems treated as
> data in /var/lib/gems.
> 
> This mostly works.  Gems can be gems and what it does has no effect on
> the dpkg managed files.  Except that /var/lib/gems/bin is outside of the
> $PATH.  So a noob user who does 'apt-get install ruby rubygems; gem
> install rake' and then types 'rake' at the command prompt is not going
> to get what they expect.
> 
> One option is for the install of the 'rubygems' package to fix up the
> path and add /var/lib/gems/bin.  I'm not sure about Debain policies
> regarding path modification with package installation but I do know
> doing it is not necessarily as straight forward as it would seem.
> Different runlevels and users have a different $PATH.

They should follow the lead of Debian's version of CPAN and symlink the 
binaries into /usr/local/bin, but I'm not sure they'd consider this (or 
at least they need some help from the RubyGems end. See http://
bugs.debian.org/403407)

--Ken

-- 
Ken (Chanoch) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/