On 2007-07-26 20:32:32 -0400, Donavan Pantke wrote:
> > there is already a vendor-ruby patch and i use that successfully. but
> > gem itself has no notion of site-ruby or vendor-ruby at all atm.
> >
> > but as a packager i can say, this is not a problem. as gems barely
> > overlap (only with scripts in the bindir).
>
> That's true, if you're not an FHS purist (it's well known that Fedora
> and
> SuSE are not, but Debian and some others are). At that point it's not about
> overlapping, it's about pure location.
than you would wont one dir for pure ruby gems and one for native
extensions e.g. i am not sure you want to do that inside gem. another
thing that works with ruby extension in general is to install native
extensions for multiple architectures into one directory tree. thats
something that doesnt work with gem either.
> > a point that might be more important for packagers are hooks to prevent
> > gem from uninstalling files installed via rpm e.g. so if you package a
> > gem inside an rpm. "gem uninstall" should not be able to remove it.
>
> And this system would solve both problems: Debian folks could link
> things
> into FHS locations as necessary, and the gem uninstall behavior would protect
> repackaged gems.
> Also note that the symlink behavior is optional; Folks that are a
> little
> looser with FHS specs could place the real files into the VENDOR_HOME
> directory, people tight can just use symlinks.
i think installing into VENDOR_HOME and symlinking back to the normal
location would be the better way. that way gem uninstall could just skip
all gems which are installed into the VENDOR_HOME dir.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
