I'm slowly battling through making the contents of /usr/share MI,
primarily so that we can ship just one copy of this with releases
(particularly CD-ROMs) and also for sharing /usr/share amongst NFS
clients and just plain aesthetic and feel-good reasons.

One thing that occured to me was that it's pretty useless to rip out all
the /usr/share files and directories out of existing sets and make a "share"
set because it's gonna contain everything from all the other sets.  So going
for a minimal installation would still include all the /usr/share cruft
from the other sets that you didn't want anyway.

The obvious thing that comes to mind is to create two files for each
set, one the same as the current set sans the /usr/share files and a
second with just the /usr/share files.  The existing set descriptions
don't need to be changed, just maketars and makeflist to build the extra
share sets.

One idea for the names of the set files is to append _s to the set
name for the share files, but then the set names longer than 6 chars
(xcontrib and xserver) don't fit into a DOS compatible 8.3 naming scheme
anymore.  Maybe it's as simple as making the last two chars of the share
set's names "_s", truncating where necessary, so these longer ones would
be just xcontr_s and xserve_s.

As for packaging, we can just put an top leave share directory in the
release hierarchy with symlinks from the various ports binary/sets
directory pointing there similar to how the m68k is done now.  It
shouldn't take too much to teach sysinst and the script-based installs
about extracting the extra sets.


This could probably be solved a lot cleaner with Jim Wise's system
package framework, but we're not there yet.  If that could be ready for
1.5, then hopefully all this hackery would then be a moot point...

Until then, does this sound like a reasonable way to do things?

Simon.