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

Donavan Pantke avatar at spellboundnet.com
Thu Jul 26 20:32:32 EDT 2007


On Thursday 26 July 2007 19:13, Marcus Rueckert wrote:
> 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).

	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.

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

Donavan


More information about the Rubygems-developers mailing list