On 1/8/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > 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.
At least the packages we have in the ISO should be recompiled. I can only see this being done as a part of a major release, though, where efforts are concentrated on recompiling new packages. > 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. WrapCompile seems to reflect better what it is, but now that I'm used to its name I don't care that much :-) > 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. I think we're going need to break compatibility with older releases on binary packages, but again, this is only going to happen on a major release of the distribution. InstallPackage can be instructed to look at $goboIndex and with base on it being empty or not select one or another repository for binary packages, so that one can keep updating their Scripts packages on old installations. Anyway, keeping both trees is doable, but is certainly going to generate some bloat in the code. If we're thinking about migration of old installations to /System/Index, then a script to create its hierarchy and download precompiled packages is fine, but I'd only see that as a way to ease migration, and not for eternal coexistence. New packages installed on such a system should all have been compiled against /System/Index. > > 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? ZSH's view, or KDE's (konqueror) view, or Vim's view, and so on, depending on which application the user's using to interact with the filesystem. As I only see /System/Links as a temporary place, I don't see files from new installations appearing there -- unless we keep using /System/Links for end-user interaction, and keep /System/Index "hidden" in some way. But of course this can (and should) be discussed better. > > 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. Yes, to the user that makes sense, but not for the new applications, which was the example I was talking about (they're not going to refer to /System/Links in any way). -- Lucas powered by /dev/dsp _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
