Hi all, I'm writing this while offline, so excuse me for the lack of quotations, etc.
---- The various directories under /System/Links act as a union of all "directory categories" the various installed programs have (eg, all include/ directories as /System/Links/Headers). It would be nice to be able to just union-mount these hundreds of directories into one directory, instead of merging them using symlinks, but that is not scalable. The plan is to implement an userspace filesystem using FUSE that will act as a custom unionfs for GoboLinux. * Being implemented in userspace, we have more possibilities for efficient/scalable internal representations for the union * FUSE is included in the vanilla kernel, whereas unionfs is not yet. * FUSE returns pid information along with calls, so we'll have the possibility of displaying different trees to different programs, based on their dependencies: programs with incompatible dependencies will be able to coexist in the system. I started to work on this back in 2005 during my intership at IBM Research. The work I developed there -- a prototype for this userspace filesystem, called ViewFS -- has since been open-sourced and is available at the GoboLinux CVS repository at Savannah. It is not currently in a useable state, as I started a rewrite of it a while ago. The plan is to get it from prototype to production state over this year. ---- My thoughts on the /System/Index transition: 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). 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)). Another feature of GoboLinux is that we merge things like bin/ and sbin/, man/ and share/man, and so on. I haven't checked Lucas's patch yet, but I would still like it to be the case with /S/I. One thing that Andre pointed out to me: /S/I is not Rootless-friendly as /S/L. I know a lot of people wouldn't like to lose the ability to run GoboLinux in a rootless environment, so we need to think how to proceed on this as well. In some Linux systems, running and unprivileged ViewFS daemon will be a possibility, but other systems won't have FUSE installed by the administrator, or don't have FUSE at all, such as Cygwin and OSX. We never "officially supported" those environments, but I don't think anybody wants to "give up on Rootless" either. My super-simplistic suggestion to this problem: on Rootless, just let Compile write over ~/S/I. Then, before SymlinkProgram, grab all non-symlink files (and symlinks that don't point to files under ~/Programs) and move them to the program's /Programs entry, and only then SymlinkProgram it. Yes, for this to work only one compilation can run at a time, but I don't think this is a severe restriction for Rootless. On /S/I and /S/L coexistence: I haven't thought much about this yet, but it should be possible. I wouldn't generally recommend this to users, though, as quirky behavior may arise (stuff compiled where half of its dependencies use /S/I and the other half /S/L) which could make phasing out /S/L hard in a live system. To be honest, I consider the move to /S/I a legitimate reason to do a reinstall; it's a pretty big change. -- Hisham _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
