From: Eivind Eklund Date: 2005-10-04T22:22:28+09:00 Subject: Re: Gems is over engineered On 10/3/05, Trans wrote: > Eivind Eklund wrote: > > Actually, there's some reasoning behind the madness: > > - We try to support users that want read-only for certain directories > > - We try to make it possible for users to share as much as possible between > > different architectures > > I realize there's method behind tha madness. But I would point you to > Gobolinux for interesting couter-argumetns. [Gobolinux use a one-dir-per-package model. -Eivind] I think both models should be supported. Gentoo use the same model as GoboLinux, I believe. The problem I have is with people coming and telling me "I am going to force all FreeBSD and Debian and Red Hat and etc users to go with my completely incompatible setup, because your work is too complex for me and I've tried out packaging 0.5% as many packages as you have for 1% of the number of users you have and my way is better and there's no reason for you to do all your stuff cause mine has worked fine so all your complexity is just stupid." I'm not going to tell Gobolinux not to experiment with this. I think Gobolinux experimenting with this is GOOD. If that works out really really well, it will take over the Linux packaging world, and we'll just kill the *BSD and Debian and PLD and etc packaging models and the Linux Filesystem Hierarchy Standard, migrating to a system that works a la Gobolinux and RubyGems. Until we do, however, I think that having Ruby implemented in a way that makes it possible to follow the standards reasonably well is necessary. And until I stop hearing complaints that it's impossible to package Rails and RailsGen properly (which I last heard from a new repackager a few days ago), I won't think this problem is solved. > > lib is by definition architecture specific (unshared) and can be read only, > > while share is architecture neutral and possible to share. Both should be > > able to be read-only except during install. Data that vary should be put in > > /var. > > Hmm... by that definition then most of site_ruby should be in share/. Yes. site_ruby is (AFAIK) inherited from site_perl, and I think that predated the proper share/ splitting. > > This was originally intended to protect the share/ and lib/ directories from > > corruption due to the amount of changes. Nowadays, it is more important that > > it let the user take backup of static data (lib/, share/) only occasionally > > and varying data frequently, and can have the varying data on different > > kinds of media (e.g, RAID-0+1 instead of RAID-0 with backup). > > Though I really wonder how many people do such a thing. Not many for each particular case. The ones that do are often very much power users, however, and contribute disproportionally to the system, and additionally there is a much larger number that don't use it, yet feel more comfortable with the system because it's there in case they need it. > Handling high > traffic/shared areas like home/ and var/ separately is a no brainer, > but splitting hairs over share/ and lib/, not to mention the local > variety. it gets to point where the "solution" is more trouble then the > problem. For some time now I've been convinced that we need to move > beyond these location based catagories --doing so would allows much > more fluid constraints and access. I don't care that much about share/ and lib/ either, and I don't know of any OS that care much about keeping architecture independent data out of lib (though everybody tries to keep architecture dependent data out of share/). The share/ and lib/ split is just an optimization when it comes to data files. It's more important for documentation and examples, so the users can find the docs when they look for them. > > There's reasons for each and every one of the directory recommendations, > > some important, some not so important. I'd be happy to go through them with > > you (tomorrow or tuesday) if you're so inclined. I don't know of any central > > repository for the information. > > A rundown posted here certainly might be helpful to many. I would prefer to go through with Austin privately and then do the public rundown afterwards; initial discussions with too many participants tend to be less than fruitful. > I'm familiar > with the much of it, I've quickly read over the FHS. And I am a Debian > user. I just think it's getting dated. I think it's important to go through and find exactly what parts are worth support and which parts we'll just want to say "So long with that". After having gone through and found what we think we can drop, I'd like to discuss it with some more repackagers, to make sure we get a good solution. > Actually I worry about MS' WinFS for Linux' sake. It may be behind schedule, but that's > what MS is working on to be sure. I'm not particularly worried. KDE is working on technology that fill similar goals, GNOME has some already, ReiserFS include some parts, and overall I don't think it makes that much of a difference. If anything, I'm worried by .NET. This kind of infrastructure could become a security must on a more hostile Internet, and that could put a several year dent in Open Source technology (and even more in open source trust.) Eivind.