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. Also, just pointing to the document isn't enough. They should also explain, in detail, potential problems that would be caused by "violating" the FHS. If the only real problem would be that "it violates the FHS", then I'm not sure that's a good justification to change the status quo... My .02, -- Chad _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
