On 10/20/07, Luis Lavena <[EMAIL PROTECTED]> wrote: > Even the contributed recipe is using a older version of rubygems (0.8.11) > > > > "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." > > > > Yeah. Whoever chose /var/lib chose wrong. But GoboLinux doesn't follow > > FHS, if that's the item in question. (GoboLinux is approaching it from > > a Mac-like approach. Unfortunately it doesn't quite work as well as > > that, and even the Mac still uses /usr and /usr/local and /opt and > > /opt/local...) > > > > GoboLinux actually create some hidding symlinks for those /usr > /usr/local and /opt /bin /etc... they aren't the real ones. > > I found less intrusive the compile and packaging process of GoboLinux > than any other packaging on linux... but that is too subjective and my > POV...
No, I agree. I think GFHS has it all over FHS. It may not be perfect, and personally I think maybe they went a bit too far --if they were a bit more conservative they may have a large following, but in anycase it certainly is a vast improvement over the status quo (from my POV). > Trans: could you be clear if you're talking about GoboLinux or debian > use of forced gem store location? Debian. Sorry for any confusion. I just mentioned Gobo in light of my hard-code discovery (they would been very disappointed by such a sight ;-) I just finished installing the new Ubuntu release from scratch, and I decided apt-get RubyGems b/c the current .deb version is pretty up to date. But then I couldn't find where the gems were going, which is how this came up. T. _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
