Re: glibc; introducing slashpackage-foreign

[Paul Jarc]

"Alfred M. Szmidt" <ams@kemisten.nu> 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