Re: clarification of ruby libraries installation paths?

On 24/10/07 at 05:14 +0900, Gonzalo Garramu wrote:
> Lucas Nussbaum wrote:
>>  And how do you avoid clashes between third-party libs installed via
>> apt/yum and third-party libs installed manually?
>>
>> Same with binaries: you have to install manually installed binaries (or
>> binaries installed by gem) in /usr/local/bin:
>>
>> apt-get install rake ; gem install rake ; gem uninstall rake should
>> restore apt's rake
>>
>> gem install rake ; apt-get install rake ; gem uninstall rake should keep
>> apt's rake untouched
>>   
> To be honest, I'm somewhat with Austin here. There's two main ways you can 
> see, say, apt-get and gem working together and within those two ways, 
> several behaviors.
>
> a) The way you describe, where they are two separate entities that never 
> overwrite each other.   You can work like:
>        1) What you described.  Each takes precedence over in the user's 
> path based on what the user typed
>            (what you described).
>            Sounds lovely until you realize you will then end up quickly 
> carrying around basically two full ruby trees.
>        2) apt-get takes precedence.  installing a gem does nothing if 
> there's an apt-get file for it.
>        3) gems always override apt-get in user's path.  User must uninstall 
> the gem first if he upgrades with apt-get to later
>            version.
>
> b) Where they do overwrite each other.  If I do apt-get install rake and 
> then gem install rake, you could work like:
>        1) apt-get's rake is gone forever and I can never get it back unless 
> I do apt-get install rake again, which would
>            then override gem's stuff.  If they are different versions, you 
> may end up with some "junk" left behind of files
>            the new (or old) version no longer needs.        2) gem has, 
> say, apt-get .pkg knowledge, so that:
>                      apt-get uninstall rake then becomes the same as gem 
> uninstall rake.
>
> Comments
> =======
>
> a) sounds ideal, but I'm with Austin here.            a.1)  That road leads 
> to madness.  Been there, done that.                     Users get confused. 
>  Sysadmins get confused.  Developers get confused.
>                     Two ruby trees, two gem trees, two site and local 
> installs.  Efficient, it ain't.
>            a.2) Seems a very silly way to work.  Package maintainers will 
> like it, users probably won't.
>            a.3) Probably the most sensible way to work with method a).  
> Package maintainers will hate it thou.

(a.3) seems like the only choice if going for (a). Furthermore, it's how
it works currently with normal software.
I if ./configure ; make ; make install $RANDOM_C_APP, it installs to
/usr/local/bin, and takes precedence over what's in /usr/bin.

The only thing that need to change in Ruby to make this possible is
cleanup/standardization of its installation paths.

> b) sound less ideal, but it is much more sane.
>            b.1) Sucks, but it is very logical and people don't have that 
> much issue learning about that behavior.
>                    Both package maintainers and users have the same 
> problem.  They CAN overwrite each other's stuff.
>                    Deal with it.
>            b.2) Ideal, but good luck merging rpm, dpkg, etc. into gems!  
> Really hard for gem developers to maintain.
>                    Madness also ensues, due to people's preferences and how 
> each distro works.

no, of course, (b.2) is a nonsense.
(b.1) looks very dangerous. It might silently or noisily break a lot of
things, like checksuming tools that check that all files installed by
packages are still identical to what's in the package.

I'd personally favor (a.3) over (b.1). The problem is that (b.1) is the
current ruby/gem behaviour, while (a.3) would require some minor changes.
-- 
| Lucas Nussbaum
| [e-mail]   http://www.lucas-nussbaum.net/ |
| jabber: [e-mail]             GPG: 1024D/023B3F4F |