Re: new sysinstall

[mark@xxxxxxxxxx (Mark Valentine)]

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
>
>--prefix=/usr/local/whatever-x.x.x
>
>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).
>
>eg.
>/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
that package).

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
local, either.]

		Cheers,

		Mark.
-- 
"Tigers will do ANYTHING for a tuna fish sandwich."
"We're kind of stupid that way."   *munch* *munch*
  -- <http://www.calvinandhobbes.com>