2007/1/8, Lucas C. Villa Real <[EMAIL PROTECTED]>: > 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. > Yes, if you missed it I refered to the release of 014 for the changes (or 015-016 if it incorporate the filesystem manager as well).
> > 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 :-) > Some people seem to be fond of well-describing names... ;) > > 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. > Will compability really be broken? If /System/Links are links to corresponding dirs in /System/Index everything will still be accesible where expected. Keeping both dirs is good because some people, like my self, don't install new versions of a distribution just for the fun of it. I'd rather just update my running system (if possible). > 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. > Exactly! But I think we should keep support for both directories for at least one major release and perhaps even keep the directories coexistant for two major releases. And I don't think it's going to add any bloat to the code. All that's needed is just some text to $PATH and similar, right? > > > 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. > For the views, that discussion can wait until some real draft for the filesystem manager is considered. For the other discussion, even though the long names in /System/Links are attractive, I'm not that attached to them that I cannot change :) Perhaps the /System/Links approach can be dropped with the new hierarchy and some other sollution be implemented? > > > 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). > -- /Jonas _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
