mpb wrote: > How does Compile not already work for both root and non-root users? > It works fine, but it's not completely "safe". One of the problems Recipes and Packages face is the dependency list. ChrootCompile is designed to use an isolated environment so that we can be sure that the recipe & package we create is "perfect" and would work for anyone. The ideal of GoboLinux is that Programs are self-contained entities. It should be possible to bzip2 a program you have installed and send it to someone, and it'll work on their computer too (assuming the architectures are the same). I'll just add while I'm on the subject that it's in this sort of situation where it would be nice not to have to do a whole InstallPackage thing to try the program, then remember to RemoveProgram afterwards...
Here's an article about ChrootCompile if you're interested: http://www.gobolinux.org/?page=chrootcompile Lucas C. Villa Real wrote: > On 7/29/07, mpb <[EMAIL PROTECTED]> wrote: > >> "UseProgram GCC 4.1.2" versus "MountProgram GCC 4.1.2". >> >> Both are just as easy to remember and use. "UseProgram" saves you the >> bother of having to mess with chroots. >> > > Also, that should involve the evaluation Resources/Environment, as > well as LD_LIBRARY_PATH. The interesting thing about MountProgram, > though, is that one could specify a wide range of programs so that a > completely isolated environment could be created, composed *only* by > the desired applications -- that's not possible with an approach based > on UseProgram. > Thanks Lucas, that's exactly the sort of thing I'm getting at. We may want to mount in a few programs that depend on each other. I do think there would be a place for a UseProgram or RunProgram-type script, because we would need a nice way to automatically mount all of a program's dependencies and run the Program's default binary. For example, the following could invoke the Firefox browser that is stored in the Firefox-2.0 Program Directory in the current directory, because the /bin/firefox binary is stored as the "default binary" for the Program: RunProgram Firefox-2.0 Also, would I be right in thinking that the line between Compile and ChrootCompile would become blurred at this point? Compile could simply MountProgram all of the Programs listed in the Dependencies, instead of having ChrootCompile unpacking a new set of packages every time. Of course then we have the problem of Programs on the system maybe having been modified and introducing quirks, but I don't think that's the main thrust of ChrootCompile is it? I realise that in these suggestions I'm actually also assuming my idea of removing version subdirectories from programs, so I might as well outline it properly. If instead of having Firefox/1.5/bin and Firefox/2.0/bin we allow the user to rename the Program directories, we would have something more like Firefox-1.5/bin and Firefox/bin. This means that the complexity of installing and running a program is greatly reduced, because it doesn't have to be merged into an existing hierarchy, which is a process that alienates the user from the system. (It's "magical".) Instead, the user can just unzip the package and be ready to go (with RunProgram ./MyProg). The price is that it becomes much more difficult to find which Program our dependencies are in. Maybe we just look in the most obvious places (/Applications/... and /System/Programs/...) for the default Program name and ask the user if we can't find it? If he's moved it or renamed it, he'll almost certainly know where it is. A user who would forget wouldn't bother renaming it in the first place... The latter problem has no one beautiful solution, but for me it's worth the difficulty if it means I get more control over my system. As a desktop user, I want to tell my system what to do, not vice-versa, and I want to be able to do it easily. I'm aware that this idea introduces chaos, which makes a programmer wince, but we must work *with* a user's unpredictability and not fight the user :) (Sorry to ramble again!) Paul
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
