Subject: Re: Notes and Thoughs on System Packages
To: None <>
From: John Darrow <>
List: tech-pkg
Date: 09/23/1998 14:16:48
In article <> you write:
>On Sat, 19 Sep 1998, Jim Wise wrote:
>:     Alistair Crooks has recently put together changes to use
>:     ${LOCALBASE}/etc/pkg and ${X11BASE}/etc/pkg to store package
>:     registration information, which is a big step toward solving
>:     this problem (yahoo!).  Presumably, system packages will use
>:     /etc/pkg, although this leaves open the question of what to do
>:     if you share /usr between multiple client machines.
>Admin from the server.  If you're sharing /usr, you don't want to delete
>stuff in /usr from a client box.

But this doesn't solve the problem.  We should be able to do a 'pkg_info'
from any of the clients and see all the system packages listed.  In this
setup, we'd only see them on the server machine.  And who says that the
files are in /usr on the server machine, or that it is even (necessarily)
running netbsd?  For quite a while our system had much of /usr shared via
nfs from a server running HP-UX 10.20 (while eagerly awaiting the release
of netbsd/hp700 :)

Taking a look at the current sets/lists files, other than base and etc,
there is very little done outside of /usr.  Currently, the comp set includes
the /sys link (which is wrong, IMO, as it hardcodes to /usr/src/sys, and
many people do not keep their sources there) and /var/db/libc.tags (which
is rebuilt with a make build anyway), the secr set has kerberized versions
of /sbin/init and /bin/ed, and the games set includes some files in
/var/games/hackdir and /var/games/phantasia.  The etc set is entirely
outside of /usr.  Only the base set includes large numbers of files both
in and out of /usr.

I would propose that the non-{base,etc} 'packages' be prefixed in /usr,
resulting in a package db directory of /usr/etc/pkg.  This would give them
a parallel structure to the non-system packages (e.g. ${PREFIX}/include for
include files, ${PREFIX}/share for sharable files) [1].  Since we are
already planning to split the current /var/db/pkg into multiple
.../etc/pkg directories, adding one more shouldn't require any additional
code, and should in fact simplify things by preventing the need to distribute
the stuff in /etc/pkg to multiple machines with a shared /usr.  The base set
could probably split into /usr and non-/usr portions without too much
difficulty, thus allowing the /usr portions to be installed from the server
(or from one specific client machine given rw access for the time being)
and the non-/usr portions on each separate client.

As a corollary to this, this would allow the X sets to be converted into
packages rooted at /usr/X11R6, thus resulting in /usr/X11R6/etc/pkg, and
allowing just /usr/X11R6 to be shared on some systems, rather than the
entire /usr.

As suggested in another message, though, we do need to come up with some
way of allowing pkg_* to deal with such situations as shared /usr/share or
/usr/pkg/share with separate /usr or /usr/pkg (such as mounting .../share
read-only from a machine of a different architecture).  Perhaps some flag
to pkg_add and pkg_delete to (silently) ignore failures to overwrite/delete

[1] The most significant place where this would not _currently_ match up
with the pkg hierarchy is in the man files.  But, ideally, shouldn't pkg
man files go into ${PREFIX}/share/man/* instead of ${PREFIX}/man/*, since
they are mi text files/roff source, anyway?

>-- Todd Vierling (Personal; Bus.


John Darrow
Computing Services, Wheaton College, Wheaton, IL