2007/1/8, Lucas C. Villa Real <[EMAIL PROTECTED]>: > 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. > Well, I thought in the meantime, when users (devs) might keep their /Systems/Links, as recompiling _all_ apps might be a bit too much. :) Also for users not adopting /System/Index directly, then having both paths in the variables allows users to install packages with the new format on older systems. Perhaps not supported, but still useful.
> > > 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. > Never mind. I made an error when I saw your changes to ChrootCompile. Perhaps ChrrotCompile is a bad name as it actually doesn't do any real compilation, it just calls Compile inside the chroot. > > 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. > Ah, now I think I see what you're refering to. For that I think that /Programs/Foo/Settings/Foo/1.2 and /Programs/Foo/Settings/Foo/2.1 is a better alternative for versioned settings. > > 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. > Yes, this was my idea as well, but I understand why you didn't implement it. I just wanted to make sure that we had the same idea. > > 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. Well, the change to /System/Index is a big change, as apps compiled with this prefix will not work on older systems (unless variables include both paths), and such large changes in the file system "API" (can't find a better word) will make users confused at first (as this change probably will be forced upon them). The question is: will the filesystem manager make any further changes to this "API", that the user will notice, in forms of forced updates? For example: the update to the new file system "API" forces users to upgrade (at least) their Scripts package to use the new packages while the inclussion of the filesystem manager is contained in one release of the Scripts package and the users might not even know that something's changed. If the latter is true I see no problem in making these changes in two separate releases, starting with /System/Index in GoboLinux 014. If the latter is false, and the filesystem manager proposes large changes as well, the only alternative I see is to implement these changes at the same time, perhaps in 015 or 016. /System/Index could still be used for development, but should not made official. > 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. > I really can't see what you're meaning with this, as, to me, /System/Links, if kept, is used primarily for user interaction. How is the changes in /System/Index going to be reflected to the user? Which application's view is the user presented with? > Since all packages are going to be recompiled anyway, /System/Links > are of no sense to the applications itself. > No, I think of this as the user interface to the files, as stated above. -- /Jonas _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
