Re: filesystem hierarchy

[Eli Green <eli@xxxxxxxxx>]

On 2006-11-14, Matthew Dillon wrote:
> :
> :Matthew Dillon wrote:
> :>     At the moment we have no plans to integrate package management 
> :>     directly into the filesystem layer.  We do have tools already
> :>     available (varsyms) to make this possible, and pkgsrc makes things
> :>     easier by installing into /usr/pkg, leaving /usr/local available to
> :>     the user.
> :> 
> :>     But, primarily, we are dependant on pkgsrc's installation management.
> :
> :Um, wasn't this planned for 1.8?
>
>    I don't think so.  pkgsrc is pkgsrc.  We have no plans to hack it.  I
>    do recall Joerg mentioning multi-version libraries but I don't know
>    if that's in his current plans or not.
>
>    It is possible to create independant pkgsrc environments using NULLFS
>    and/or varsyms.   In particular, one could make /usr/pkg a varsym
>    pointing to the correct directory (instead of just being a directory),
>    and then use varsyms to create entirely independant pkgsrc environments
>    for each major service running on the machine.
>
>    I would personally like pkgsrc to have the ability to install multiple
>    versions of a package, but that is support that the pkgsrc people would
>    have to add, not us.

Couldn't it be more granular than that?

It seems to me that DragonFly is not very far from the stated goal of
having multiple libraries as it is, using varsyms or maybe a slightly
specialized version of nullfs:

foo-1.0 depends on libfoo-1.0
bar-1.0 depends on libfoo-1.1

/pkg/foo/1.1
/pkg/bar/1.0
/pkg/libfoo/1.0
/pkg/libfoo/1.1

then /usr/pkg is just a collection of symlinks, where:

/usr/pkg/bin/foo -> /pkg/foo/$foo_version/bin/foo
/usr/pkg/bin/bar -> /pkg/bar/$bar_version/bin/bar
/usr/pkg/lib/libfoo.so -> /pkg/libfoo/$libfoo_version/lib/libfoo.so

This is all stuff that's supported right now. The only magic is that
instead of doing straight symlinks for the executables up there, they
would be shell scripts that would go through all the dependencies of
that executable and set the $foo_version, $bar_version and
$libfoo_version accordingly.

In fact, they could all link to a single executable that checked
argv[0], figured out which package was being called (based on
already-set environment variables or choosing the latest version if none
are set) and then set the version numbers.

The idea here (in my mind) would be to make this scheme co-exist with
pkgsrc by just having pkgsrc install to /pkg/$pkgname/$pkgversion
instead of /usr/pkg. This doesn't sound hard. Getting pkgsrc to convince
configure scripts to search the right directories for header files might
be trickier. Or, I guess it should just search /usr/pkg with the right
environment variables set.

Is this sort of what you meant? Is there some glaring fatal flaw in this
scheme?