On 1/10/07, Hisham Muhammad <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm writing this while offline, so excuse me for the lack of quotations, etc. > > ---- > > My thoughts on the /System/Index transition: >
I'm so far behind in email I'm not sure what this is. Don't bother explaining I'll catch up (I hope). > I don't know if we'll be able to use /System/Index already in 014, as I think > we all agree that we shouldn't take too long to make the next release. We > definitely won't be using ViewFS by then (I'd expect it to debut in 015 or > 016). I don't foresee incompatibilites between a links-based /System/Index and > a ViewFS-based one; in fact, a minimal links-based /S/I will be needed to > bootstrap the system before the userspace daemon is up. > > If we don't use /S/I in 014, then I propose at least one other transitional > change (and I know I'll be hated for this) -- to do the lib->Libraries link in > /Programs entries similar to the share->Shared scheme we have now. I know I > was against this for the longest time, I know it "looks ugly", I know a lot > of people asked for this many times. > > So, what has changed my mind? A few things. > > First, there's all the reasons pointed out by earlier proponents, which are > valid and I never refuted: it will really reduce the amount of hacks in > recipes. "But we managed to live without it this far!" That's no good > counterargument, since stuff like Gnome and scripting languages have been a > constant source of pain because of lib/ interdependencies. > > Second, about the "ugliness" of it: thinking about it, it's one ugly hack > applied consistently versus an unbounded number of ad-hoc hacks we've been > using over the years (environment variables, configuration files, path tricks, > etc.). > > Third, it's a _transitional_ solution: I've had ViewFS in mind since 2005, but > it is taking way longer to see the light of day than I ever expected (due to a > number of unrelated reasons). I've always avoided hackish solutions when > there's a better, more correct one in sight, but we could have something that > "at least works" until the "best approach" is not available -- so let's keep > /S/I in the horizon but in the meantime let's use lib->Libraries to clean up > recipes and improve the system we have right now. I think we need to implement > the lib->Libraries link as soon as possible; we've been suffering needlessly > all this time (I told you I'd be hated for this). > Ok. #3 is good. It'll clean up the recipes for /S/I too (Guessing /S/I is the install path vs search path thing we talked about forever ago.) > Back to /S/I: > > Things to keep in mind: a links-based /S/I _requires_ unionfs in order to > install programs. In principle, I am opposed to make a GoboLinux release > that's dependent on non-standard kernel features (but I'm not unable to change > my mind (see above)). > There are unionfs's based on fuse. Last I looked (1.5 years ago) they were fairly flakey but they should have progressed since then. PS. I just got a MacBook that I'll be putting Gobo on. I should be more active again. -- Carlo J. Calica _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
