Subject: Re: PROPOSAL: NetBSD System Packages
To: Jim Wise <jwise@unicast.com>
From: Robert Elz <kre@munnari.OZ.AU>
List: current-users
Date: 09/30/1998 14:30:46
    Date:        Tue, 29 Sep 1998 15:25:55 -0400 (EDT)
    From:        Jim Wise <jwise@unicast.com>
    Message-ID:  <Pine.GSO.4.01.9809291509450.3583-100000@alpine.unicast.com>

All that looks pretty good to me - I noticed just one concern ...

    1.2.1 Root/User/Share separation
    
	[...]

    The second step, that of insuring that a client can choose to install
    only the parts of the system which reside on local volumes can be
    most easily addressed by careful consideration of package contents.
    A look through the contents of the current install sets suggests
    that relatively few packages will in fact need to install in more
    than one of /, /usr, /usr/share and /usr/X11R6.  Were such packages
    split into separate components, based on filesystem boundaries,
    users would easily be able to install only the parts which are local
    in their particular configuration.

That looks to me as if there's to be some idea of which parts in the
filesystem might be going to be shared, in fairly large chunks.

I suspect that this will be insufficient - and perhaps surprisingly, also
much harder to implement than a much more general solution.

What's really needed is a way for the user to say "don't install in this
directory, that's shared, and has already been done" - for any directory at
all.

By simply implementing in the package install mechanism a yes/no list of
directory prefixes you get all the generality you can possibly need there.
The installer just scans the list (in order), comparing the prefix, and when
it gets a match on the prefix, takes the yes or no which has been specified,
and immediately knows whether to install the file or not.   Couple that with a
"never overwrite" option (never alter a file that exists already, with or
without a warning), and there's essentially nothing that anyone might want
to do which can't be handled.

All that's left then is building the yes/no list - that needs to be automated
of course, which I think can be done for the majority of cases fairly simply,
based upon a starting point of "install all local, nothing NFS" by parsing
the output from mount, sort -r on the mount point, attach a "no" to all the
NFS mounts, and a "yes" to local mounts (and whatever you like to the exotic
stuff - installing in mfs filesystems seems a bit fruitless for example).

Then you give the user the ability to "install on NFS" which would flip all
the NFS generated "no" flags to "yes", and the option to individually flip
the flags (perhaps with an easy way to flip to yes the standard mount points
for private filesystems of diskless systems) and also add/delete entries from
the list for those with really peculiar needs.

The list used at system install time then gets saved somewhere, and used as
the default later for all future package installs, of the system packages or
of the 3rd party set (and if needed, can be edited of course, and probably
overridden by a command line option).

kre