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