["system" packages]

>>Actually, I've been advocating that for some time now :-)

Jason isnt the only one...

>If this is generally thought to be a Good Thing, I would be willing to
>take on doing a pkg-ification of -current's install stuff...  At least
>to do an interface spec and a first stab, so we can see what goes
>wrong...

We thrashed out a lot of the isssues re: pkg-izing binary
distributions once before.  There were a lot of conflicting
requirements and opinions about:

	* the large granularity of what now gets installed from
	  individual sets like ``base'' (people who dont want UUCP, ...)

	* strong opposition to forcing everyone to choose
	  whether or not to install dozens of fine-grained pkgs
	  (common case is to install everything)

	* Bloating the install media for popular platforms beyond one
	  floppy, since we need pkg_install tools to unpack
	  stuff rather than just tar for .tgz files

	* Granularity of packaging the sets
	  (how many tarfiles do you have  to suck down from an FTP
	   site, and then check you've got them all?)

The consensus back then was a hierarchy, with `set' files containing
pkgs:

     * Partition at least `base' into individual pkgs
       at the rough granularity of, say, "uucp" or "rcs",
       or  "normal" vs "profiled" libraries.

     * Ship sets as one .tgz file  containing a .tgz pkg file
	for each `package' in that set.

     * Allow users to choose to install everything, or select
       individual sets, as we do now.

       Plus for set-by-set, an `expert' option to select individual pkgs
       within each set, (so an expert can tailor an install for,
       say, a 4Mb RAM/80MB disk i386)

     * the `tailored install' menu was sposed to be generated from a
	CONTENTS-like file in each set, not hardcoded into sysinst.
	I think menuc can now do scrolling menus, I dont know about
	runtime-generated contents, though.  

The set-as-tarball-of-pkgs change is fairly simple, if you punt for
now on the UI changes.  Mostly sh-script hacking to build the sets,
and then using the existing parse-and-loop machinery in sysinst to run
pkg_install over a `CONTENTS'-like file, rather than untarring each
tarball directly into the target.

You might handle the bootstrap problem by a `boot-base' tarball in the
base set, which includes the pkg tools, plus pre-generated pkg
database info for the contents of `boot-base'.

Oh yeah, the other thing people suggested was tweaking the sysinst
menu hierarchy, so you an use sysinst as the UI to install pkgs on a
live system after `system installation'.

More than you intended, maybe, but adding `system' pkgs for AFS or
coda or whatever would drop out `for free' as just another
pkg-in-tarball config-file, and another menu entry for the new set.