On 1/8/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > Don't variables like $PATH must be set to include both paths?
Just if we're going to have different contents on /System/Index/bin and /System/Links/Executables (and I don't know if we're going to keep /System/Links directories). This initial step towards /System/Index is still using symlinks and no filesystem daemon to manage its contents, so it's just acting like /System/Links for now. > > Patches follow. Any comments are _greatly_ appreciated! > > > Why are you leaving out Compile? Is Compile completly independent of > these changes? Yes, there's no need to modify it. That's the benefits of using $goboVariables. > I don't see the benefit of moving /System/Settings to > /System/Index/etc, why that change? First of all the settings > directory is no clean index as it contain regular files as well and > secondly /System/Settings looks much better to me. Even though we > don't aim to change names to make them more usable (than e.g. /etc) I > think things like these are good. Indeed.. I decided to use it after having a very quick talk to Hisham yesterday's night. But as Settings are unique among all versions of an application it might fit fine under /System/Settings, I think. > For installation, I actually thought that the install directory would > be union mounted so that all writes were directed to $target, instead > of /System/Index, to be copied afterwards. I guess this is due to > using /System/Index/etc, but as I said above, I don't like that name. Ideally it should be a union mount of /System/Index=ro:/Programs/Foo/Version=rw. I just didn't took the time to implement it right, as I was just prototyping. > Having commented the patches, I also would like to comment the idea. I > really like the idea and think it would be a great solution. However, > I think we really would make a misstake if we abandomed our > /System/Links/Executables, /System/Links/Libraries etc. I don't mean > we should keep /System/Links, just that 'Executables' and 'Libraries' > is much more clear than 'bin' and 'lib' (refer to, for example, change > of 'Store' to 'PackedRecipes', which is a somewhat big change imo, but > to ease readability). If we still would keep our long names, which > actually is a selling point, I think we would reach almost an optimal > solution. Just some cents of mine (unknown amount). I also like our current names, but they'll be of no meaning in the sense of being referenced inside scripts or precompiled packages. The problem I see with /System/Links is that we plan to use a filesystem manager to deal with /System/Index views in a (hopefully near) future, letting each application to have a different view of the filesystem. If /System/Links entries were mere links to /System/Index entries then it really isn't showing "symlinks", but rather links to the currently running application's view. Since all packages are going to be recompiled anyway, /System/Links are of no sense to the applications itself. -- Lucas powered by /dev/dsp _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
