Paul Dann wrote: > I found a post somewhere (that I can't find any more!) that mentioned > a plan that I understood to be something along the lines of replacing > the program symlinking solution with a unionfs-based system. Did I > understand this correctly?
Actually I think the eventual plan is a custom FUSE-based filesystem, probably. > A while before I found that post, I spent > some time thinking really carefully about what I'd like personally in > terms of usability from Gobolinux, and this came top of my list, so it's > particularly exciting if it's already in the pipeline! My thoughts > particularly lie with programs being re-locatable (ie not necessarily in > the /Programs dir). > > I really think Apple got things right when it comes to program > installation, as I mentioned in a post on the user list a few weeks > back. I believe ChrootCompile produces packages, is that right? (I'm > afraid I haven't put much time into trying it yet.) This sounds ideal > to me. I much prefer the idea of ending up with a package, rather than > it being installed directly like Compile, and the chroot jail has > obvious advantages. such as chroot only being usable by root, or else risking security flaws if there is any bug :-( I believe ChrootCompile just installs the program when it's done, the same way Compile does. A "package" would need to be much more sophisticated. > Well, what if an unprivileged user wants to compile a program and run > it? He'll need a mechanism to get that program in the path without it > going in /Programs. Compile with goboPrefix in your home directory. It is true, installing precompiled "binary" packages doesn't work with this. Also you will need to add the Executables directory in your home to your PATH environment variable > Also, this way you can organise your programs into different > directories.For instance, you could have a directory where you store a > load of beta programs that you recently compiled and are waiting to be > thoroughly tested. You can run them from that directory to test them, > then delete the folder without installing them in /Programs. This is > especially important if there are others users (e.g. connecting via > ssh) that might try to execute these beta programs. Only if there are security flaws like setuid programs in it. In fact I'm a little worried about old versions of programs like sudo (, Xorg, ...) staying around for this reason. Gobolinux lets you install multiple versions of a program, and it usually works. Although you have a point about your own organization scheme helping you delete everything at once, for example. > One of the most important aspect of this for me though, is that I want > it to be possible to have multiple versions of the same program both > installed, and *both* able to run. For example, having Firefox 1.5 and > Firefox 2.0 running side by side, without any weird patches or > wrappers.Now I don't think this is possible right now, but I have some > interesting ideas concerning the implementation of this. I'm not an > expert on all things Linux though, so there may be a million holes in > my ideas. Normally Linux lets you run multiple versions of programs, however Firefox is evil and tries to prevent you from doing this by hooking up with already-running firefox instances. I think you would have to create separate process namespaces that cannot see each other, to make this work without patches. I'm not sure how capable linux(the kernel) is of that currently or how practical it is to use. Virtualization of a whole system _works_... > What if you want to try out Prog-2.0 whilst needing to work a lot with > Prog-1.0 (e.g. constantly opening and closing the program)?You can set > Prog-2.0 compiling and continue using Prog-1.0 without worrying about > the version suddenly changing when the compile ends... That's why I > like the ChrootCompile technique of producing a package. That's already true with normal Compile. If you don't want the new version to have any impact whatsoever on the system when installed, unless that version is explicitly invoked, maybe try `Compile --no-symlink --no-updatesettings --no-unmanaged` or similar? Myself, I'd like a way to conservatively symlink and update settings and unmanaged files if they're not there already, preferring to leave intact a previous version of the program. >> After all, there's not only the application >> to consider, but the libraries it depends upon as well. Where do >> those go? Indeed it is the dominance of libraries that makes package management be essential - in fact the lack of any decent package manager was the most compelling reason that drove me to leave Mac OS X two years ago. (Fink, at least at the time, was not decent enough for my standards, and as I've been to Gentoo, Ubuntu and now GoboLinux... looking for good package management.) Isaac _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
