Re: clarification of ruby libraries installation paths?

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.

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.

The big benefit of b.1) is that having junk files is not so terrible.  
Every two or three years you end up building a new system from scratch 
and can redist the stuff, forgetting about any junk files.   And a good 
sysadmin should be able to write a cron job that queries gems and 
apt-get's dependencies to clean up the disk, say every 3 months.  Is it 
a boring and delicate chore to do?  Yes.  But b.2 is pretty hard to 
manage, and a.1 is really well... wish you luck.


P.S.  I've dealt with similar issues at several large facilities, and 
b.1 always wins for being the least problematic and the one that trusts 
the user's brains.  But if anyone pulls b.2 or a.1, it will be indeed a 
huge leap for mankind.   Personally, I would prefer b.2 rather than a.1, 
but that's just me.

-- 
Gonzalo Garramu
[e-mail]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy