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

Donavan Pantke avatar at spellboundnet.com
Thu Jul 26 18:17:00 EDT 2007

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

        Donavan Pantke

More information about the Rubygems-developers mailing list