On 10/20/07, Chad Woolley <[EMAIL PROTECTED]> 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 don't think that flies b/c, if I'm not mistaken, that's exactly how
opt/ is used.

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

That's sort of the thing with Gems, and maybe why the Debian guys
stuck it in var/, the source cache should technically be in var/,
while the rest in /usr/local/lib.

T.
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers

Reply via email to