On Saturday 20 October 2007 01:29:14 pm Chad Woolley wrote: > On 10/20/07, Rick DeNatale <[EMAIL PROTECTED]> wrote: > > Somehow they think that that violates the FHS, or at least the debian > > policy interpretation of it. > > > > Look at the very end of: > > http://pkg-ruby-extras.alioth.debian.org/rubygems.html > > > > I can't say that I understand it, but that's what the Debian ruby > > maintainers think. > > That document really needs to quote the exact sections of FHS that are > violated, and why they consider them to be violated by Rubygems. It's > too vague to just say that RubyGems violates FHS because it "follows > the "one directory per package and version" rule." > > I couldn't find anything that said that there cannot be "one directory > per package and version" - at least not by grepping the FHS for > version. > > Here's the description of /var/lib: > > "This hierarchy holds state information pertaining to an application > or the system. State information is data that programs modify while > they run, and that pertains to one specific host. Users must never > need to modify files in /var/lib to configure a package's operation." > > However, here's the description of /usr/local: > > "The /usr/local hierarchy is for use by the system administrator when > installing software locally" > > ...and /usr/local/lib: > > "lib Local libraries" > > > I'm no expert, but based on the few times I've read the FHS (this > isn't the first) I don't understand why they just can't go with > /usr/local/lib/ structure as it already exists. I'm sure they have > good reasons, but that document doesn't go far enough to explain it. > They should state the exact phrases of the FHS that they think are > violated by the status quo, and why their decisions make it better.
I don't do Debian package maintenance, but I do understand the overall problem with using /usr/local/lib. The issue is that a system package manager should not install software into /usr/local, because that's supposed to be used for system local commands. What this means is that a system package manager can't install gems and have them in the same structure. And, it's not too fun to put the gems in /usr/lib, since I personally want to give non-root users the ability to install gems, if I so choose. Much harder to do with a /usr/lib structure, since RPM/DEB packages will possibly muck with my permissions structure. So, I mentioned in an earlier thread about the ability to have a second gem directory, (I called it VENDOR_HOME) to store gems installed by a system package manager. The gem command will treat this as read-only, and so won't install or delete gems from this directory. This means we should be able to have our cake and eat it too! I'm guessing that, in this structure, GEM_HOME will be in /usr/local/lib (with binaries linked to /usr/local/bin), and VENDOR_HOME will be in /usr/lib (and packages install the binary commands). In theory, the gem cache should be placed somewhere in /var (there are quite a few places this could be, either /var/lib/gems or /var/tmp/gems sounds appealing to me) I'm heading out of town next week, but when I get back I'll work on getting VENDOR_HOME and so forth into RubyGems, unless of course someone else wants to tackle this. :) Thanks! Donavan _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
