"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote: > I have to use './configure [...] --prefix=[...] > --with-headers=[...]' because I have every package installed into > its own hierarchy of > > Then your system is broken.
Well, it's different. That doesn't make it broken necessarily. It has some advantages over the traditional way (one of my favorites being atomic, reversible upgrades), and so it would be nice if GNU could work this way. > * Reliability of paths. > The Python interpreter will always be available as > '/package/misc/spf/python/bin/python'. > > And that won't work on any other system then yours where as ... To clarify: reliability of paths only applies to "native" slashpackage packages (such as daemontools). For "foreign" packages (such as python) that we choose to install under /package, it does indeed require a bit of (not very difficult) extra work to let packages find each other. Note that the creator of slashpackage originally intended that adoption of slashpackage would fall to authors/maintainers, not admins/distros. So /package/admin/daemontools should mean the same thing on all systems, if it exists at all, because the author of daemontools made that the default installation path. I and others have then gone beyond the original design and installed "foreign" packages under /package, even though they were not originally intended for that kind of installation. We don't get reliable paths in these cases, but we get other benefits. Most packages support --prefix or similar, and let the user specify where the dependencies are, so it's usually very little work to install a package this way. > (and env is usually installed in /bin anyway). The BSDs have it in /usr/bin. For GNU and Solaris, /usr/bin and /bin are the same. I haven't used a common GNU/Linux distro in a while, but IIRC, it was in /usr/bin there as well (though perhaps also in /bin). > It all seems like a basterdised version of stowfs/packagefs. Since it's not a special filesystem, but merely uses the existing filesystem in (what I would say is) a more intelligent way, /package works on all existing systems today. It doesn't require special help from the kernel. I don't know enough about stowfs/packagefs to compare them much beyond that. Do they allow multiple concurrently-installed versions of packages? Atomic upgrades of entire packages? Systemwide upgrades (as far down as including glibc, but not the kernel, at least in the case of Linux) without requiring a reboot? paul _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
