[Rubygems-developers] proposal for solving the RPM/DEB vs. Gems battle

Marcus Rueckert darix at web.de
Thu Jul 26 19:13:10 EDT 2007

On 2007-07-26 18:17:00 -0400, Donavan Pantke wrote:
> After reading many old threads revolving around FHS specs, RPMs and DEBs and 
> Gems, I thought of a way that the 2 could get together nicely. Before I go 
> writing code to do it (the company I work for also looks to be interested in 
> this, so it might be written by one of our real good Ruby coders.), I wanted 
> to see if this sounds like something that Gems folks wouldn't balk at.
>         Generally, Gems has taken a stance truly in the spirit of Plan9, which 
> is 
> that software is contained in an individual directory. This is real good for 
> development and ease of management from a software perspective. FHS and LSB, 
> etc, looks at the same problem from a systems management perspective, such 
> as "can we have a single directory that we can tar up and be pretty certain 
> that we've captured the config of the box? Answer: /etc". Both camps have 
> good points, it just looks like there isn't one universal answer that both 
> types of people can use effectively. So, what about making them compatible 
> with each other?
>         What I want to do is to introduce the concept of a VENDOR_HOME to 
> Gems. This 
> directory would be the location of all gems that were installed via foreign 
> package management utilities. When doing a gem list, the list is compiled 
> from both VENDOR_HOME and GEM_HOME. Gems would not install anything into 
> VENDOR_HOME, and if directed to remove a gem in VENDOR_HOME, we can instruct 
> the user that they have to use the third-party tool to remove the gem.
>         The contents of the VENDOR_HOME directory will be a bunch of symlinks. 
> The 
> third-party packager can put all files into the proper directories for FHS 
> compliance, and then symlink that directory or file into the proper place in 
> the VENDOR_HOME structure. This satisfies everone's requirements, it just 
> looks less than perfect on the file system.
>         I think the VENDOR_HOME addition will be pretty easy to implement. 
> What will 
> be harder is actually doing the split install. My hope is that Gems can help 
> packagers with that, too, by having some RPM spec/DEB control file creation.
>         Is this something that could be incorporated into Gems?

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).

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.


           openSUSE - SUSE Linux is my linux
               openSUSE is good for you

More information about the Rubygems-developers mailing list