On 2007-10-21 09:14:59 -0400, Donavan Pantke wrote:
> I don't do Debian package maintenance, but I do understand the overall
> problem
> with using /usr/local/lib. The issue is that a system package manager should
> not install software into /usr/local, because that's supposed to be used for
> system local commands. What this means is that a system package manager can't
> install gems and have them in the same structure. And, it's not too fun to
> put the gems in /usr/lib, since I personally want to give non-root users the
> ability to install gems, if I so choose. Much harder to do with a /usr/lib
> structure, since RPM/DEB packages will possibly muck with my permissions
> structure.
>
> So, I mentioned in an earlier thread about the ability to have a second gem
> directory, (I called it VENDOR_HOME) to store gems installed by a system
> package manager. The gem command will treat this as read-only, and so won't
> install or delete gems from this directory. This means we should be able to
> have our cake and eat it too! I'm guessing that, in this structure, GEM_HOME
> will be in /usr/local/lib (with binaries linked to /usr/local/bin), and
> VENDOR_HOME will be in /usr/lib (and packages install the binary commands).
>
> In theory, the gem cache should be placed somewhere in /var (there are quite
> a
> few places this could be, either /var/lib/gems or /var/tmp/gems sounds
> appealing to me)
>
> I'm heading out of town next week, but when I get back I'll work on getting
> VENDOR_HOME and so forth into RubyGems, unless of course someone else wants
> to tackle this. :)
+1
support for something like that would make my job easier aswell.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
