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?
Thanks!
Donavan Pantke
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
