In article <Pine.NEB.4.02.9809231619320.3905-100000@duhnet.net> you write:
}On Wed, 23 Sep 1998, John Darrow wrote:
}
}: >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 :)
}
}If you're installing on a net server, you have a couple options:
}
}- Install via the client.  The /etc information gets updated.
}- Share /etc/pkg (which should be trivial if you're sharing /usr).
}
}Because pkgs _do_ and _will_ put stuff outside of /usr, it really isn't wise
}to try to do adminning from more than one box when fooling with base sets.
}It's just not advisable.  The cleanest solution is and will be adminning
}from one box when messing with the base system.

Neither choice works.  Choice 1 would require installing on every client
box, thus installing (or trying to install, if /usr is already mounted ro
after installing the first one) the /usr files multiple times.  Choice 2
runs into the opposite problem:  Install once, on the 'server' or the
designated admin box, then none of the (other) clients get the necessary
non-(/usr,/etc/pkg) files.  Catch-22.

}:  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)
}
}That's the standard location; has been for a long time.  But /sys is not
}even a necessary path; none of the kernel uses it by default.  It's just
}there for convenience.
}

Point taken.

}: 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.
}
}Doesn't matter if the numbers are large or small.  The fact that there are
}files both in and out of /usr makes trying to share such pkg information
}messy and prone to error.
}

That's why we make in-/usr and out-of-/usr (which, in most cases, isn't
really needed) separate packages.  See below.

}: 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].
}
}No.  That kills mounting /usr read-only, as some programs (games, for
}example) must write files which already exist in the set, and which are NOT 
}shared.
)

Then, IMO, TRT is to try to eliminate or move those files, and if not doable,
then separate them.  Especially (and this links into a number of other
threads which have been brought up on other netbsd lists recently), it should
be possible to rm -rf /var, then rerun mtree to recreate the /var structure
and have things 'just work' (possibly with the loss of some high scores, log
files, etc.).  This is already the justification for trying to move
/var/cron/tabs elsewhere.

Specifically, for the files I listed above:

/var/games/hackdir/{data,help,hh}: all read-only, all necessary for hack
  to work, so these should be in /usr/games somewhere.

/var/games/phantasia/monsters: mostly read-only, only written to to allow
  the 'bad ring turns player into a monster' function to replace a current
  monster-name with the player's name.  This 1) rarely happens, and 2) would
  probably not be missed if removed.  Should be moved into /usr/games.

/var/games/hackdir/perm, /var/games/phantasia/{gold,lastdead,mess,motd,void}:
  all dynamic, all start out empty, the only reason we put these in is to
  make them owner:group games:games, mode 660.  Since both hack and
  phantasia now start out as setgid-games, they should be able to check for
  the existence of said files, and, if not found, create them themselves.

/sys: just a symlink, only works if the user has either put sources into
  /usr/src, or made /usr/src a symlink to their sources.  Takes up next to
  no space.  Put it into base, or get rid of it.

/var/db/libc.tags: Only usable while editing sources on a system with /usr/src
  pointing to the netbsd source tree.  Totally unused on a system without
  said source tree in (or linked to by) said location.  The only thing lost
  if it is not there is the ability to use the tags function in ex/vi.  Since
  this is only useful on a system with the libc sources, and a copy is made
  there in the first place, why copy it out to /var/db and pollute things?
  
/bin/ed, /sbin/init (secr set): the secr set has always been a difficulty,
  given that it replaces preexisting files.  In this case, I would probably
  have to punt and say make a secr-root pkg containing just these two files,
  and a secr-usr pkg containing the rest of secr, and just remember that
  secr-root has to be installed on all of the machines, while secr-usr only
  on the shared /usr.

The one other step would be to separate base into base-root and base-usr.
With these changes, base-root, etc, kern, and secr-root would only contain
files outside of /usr, and the rest of the sets would only contain files in
/usr.  The /usr files are installed once, either directly on the server or
(as may be necessary if the nfs server is a non-netbsd box, as Curt Sampson
brought up in another message) from a designated admin box (simply by
remounting /usr rw on that box, then installing, then remounting /usr ro).
Yes, the non-/usr files would have to be installed separately on each box,
but we already have to do that anyway.

Regarding /etc/pkg vs. /usr/etc/pkg:  Originally, I proposed /usr/etc/pkg
just to add a nice parallelism to the structure.  But since then, I've come
up with additional reasons to have the /usr/etc/pkg stuff separated from
the /etc/pkg, as we move (as it seems we are) more and more toward an
everything-is-a-pkg style:  If, say, base-root, or kern, is a package, then
when I pkg_add a newer kernel, or newer base-root, on one machine of a group
which share /usr, if /etc/pkg is shared, I've suddenly changed the package
registration for the whole group of machines.  This is a no-no.

}: 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.
}
}X11 is a completely new can of worms when you talk about sharing, and there
}are proposals in the works to move some of the nonshareable files into /var
}- blasting your whole proposal out of the water.  :-/  There's far more
}drive to be able to share partitions _read-only_ than to be able to make
}sure all files for a given set are in the same path prefix.
}

I agree with the proposals for moving the non-sharable files out.  I, in fact,
have done so with the systems here.  But that _helps_, not _hurts_, my
proposal.  If necessary, we can create an xetc package for the non-sharable
non-volatile files, which would have to be installed on every system anyway.
Or we can just throw them into etc--the files are small text files, just
like what's there already.

To reiterate, my proposal (taken with the one that is already being bounced
  around to move /var/cron/tabs) cleans up a lot of things.  It:

1) makes /var volatile.  In other words, we can wipe it, re-mtree it, and
   programs will simply 'just work'.

2) Allows /usr, or certain subtrees of it (e.g. /usr/pkg, /usr/X11R6) to be
   shared r/o between machines, without having to do any sort of special
   pkg-db redistribution, etc.  Thus, /usr/pkg/etc/pkg contains pkg-system
   package db files, /usr/X11R6/etc/pkg contains package db files for X,
   /usr/etc/pkg contains usr package db files, and /etc/pkg contains pkg db
   files only for the locally-installed-on-this-host packages.

}: [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?
}
}Proposed; not much work done on it.  I believe it is a good idea.
}

Agreed.

}-- 
}-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)
}

jdarrow

--
John Darrow
Computing Services, Wheaton College, Wheaton, IL
John.P.Darrow@wheaton.edu