DragonFly kernel List (threaded) for 2003-09
Re: new sysinstall
In article <3f53ab8b$0$272$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Steve Mynott <steve@xxxxxxxxxxxxxxxxxxxxx> wrote:
>I have been in the habit of running multiple installations of different
>versions of scripting languages and have found the
>switch to the GNU-like configure (found in PHP4 and Python for example
>and probably 95% of software in ports) very handy since then all files
>from 'make install' go under ONE single directory which is cleaner and
>easy to manage IHMO.
>I was just pondering whether you could extend this principle to every
>file in the system by having it associated with a package name foo by
>being under the directory hierarchy of a particular directory name foo
>(with an associated version number).
>/usr/local/php-4.3.3/bin/php belongs to package "php-4.3.3"
There's some merit in the depot-like package management policy where
every package is installed in its own heirarchy. However, in the simplest
implementation it just gets impossible to manage $PATH, and using symlinks
from a common area (e.g. /usr/pkg/bin/php -> /pkg/php-4.3.3/bin/php) just
loses the advantage of multiple installed versions of a package (and the
symlinks are impossible to manage anyway).
However, taking a hint from the QNX package file system (where the package
lives in its own area, and registering itself with the package file system
is a bit like adding itself as a union mount point in a global area), and
from the Plan 9 idea of per-user mounts, maybe we can do something with
Matt's whizzy new ideas for package management in the file system: basically
each package advertises itself to the package file system, the admin gets to
choose which version gets to appear as /usr/bin/php, for example, but the
user can say "I want version 4.2.1 of the php package, so make /usr/bin/php
be an alias for /pkg/php-4.2.1/bin/php in my view of /usr/bin" (and so on
for other utilities, manual pages, headers and libraries, everything from
Of course, if you get a good definition of the mechanism for dealing with
the VFS aliases on a per-user basis with, say, system- and group-wide defaults,
it probably ends up just as easy to implement with symlinks...
>One drawback would be ending up with
>/bin-0.99/sh belongs to package "bin-0.99"
In the scheme above, bin/sh might actually be an alias for
/pkg/dragonfly-base-1.0/bin/sh, or some version of bash for a particularly
perverse user (and of course in a Linux runtime environment)...
>A related issue is how ports usually now puts stuff in the default
>"configure" location under /usr/local.
>This tends to clash with software "configure"d outside of ports, which
>is probably why NetBSD use /usr/pkg as a base for their ports (or
>whatever they call it :) ) installation.
That's been one of my pet gripes for years, and as a result my main server
still can't have FreeBSD packages installed since it screws up /usr/local
utterly (to my annoyance, it seems that even some packages which install
only in /usr/local/foo still want to run mtree on a full copy of
BSD.local.dist - spit!). [BSD.usr.dist shouldn't even have an entry for
"Tigers will do ANYTHING for a tuna fish sandwich."
"We're kind of stupid that way." *munch* *munch*