Ok, I have to bring up this issue once more, as I've found out that there's a problem with union sandbox as well and no real solution was decided on last time this issue was up.
With fibo sandbox: when 'make install' tries to place a file or make a directory in /Programs/Foo/Variable, when there already exist some structure, it is bound to fail as the user fibo doesn't have permissions outside the sandbox, more precisely in /System/Variable, where links from /Programs/Foo/Variable points to. With union sandbox: this is only a problem when 'make install' tries to create a directory, which an earlier version of Foo created and therefore exists as a link. For example, I tried to recompile HTTPD 2.2.3, because I'm making a new revision and want to try the recipe, and 'make install' wants to create the directory /Programs/HTTPD/Variable/run/httpd. As this directory was created last time I compiled httpd 2.2.x, and the fact that 'run' is expanded, 'httpd' is a link pointing at /System/Variable/run/httpd. This isn't strange, but even though fibo has write permissions though union sandbox, it can't create the directory, because there's already a file (or a link rather) with the exact same name - and the install dies (this would be a problem for fibo sandbox as well, if the first problem is solved by giving fibo write rights in /System/Variable). I don't like to handle variable as unmanaged files. I like the fact that there exist a point (/Programs/Foo/Variable) where one can see the contents of what Foo has. What about making it a bit more like Settings, i.e. all write to /Programs/Foo/Variable are redirected (either with symlink in fibo sandbox or with union mount with union sandbox) to Resources/Defaults/Variable and then /Programs/Foo/Variable is updated with the new contents (this update is much easier then the Settings update, as new files are created, no files are merged and old files are kept). We should still use the "backlinked" solution, as I like that the var bulk should be stored in /System/Variable, not spread in different folders under /Programs, and SymlinkProgram could handle this (to move the files and to create the symlinks), but now we can handle any conflict manually, like write permissions, file exists etc. -- /Jonas Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel