[ Is everyone in this discussion on tech-install at the moment ???? ]

Ok, I've only just had a chance to go through this thread, and I'll make
some random comments...

Jonathan Stone (Wed, 30 Sep 1998 19:15:24 MST) says:

> I think the key difference is that (AFAICT) meta-pkgs just include
> dependency "pointers" to other pkgs. 
> 
> Pkgsets, OTOH, are just "containers" (like shipping containers) that
> hold a collection of pkgs inside them for easy handling. they dont
> need to be pkg-like, but we could easily make them so.

I think this sums up nicely the concept of pkgsets - "containers".
Extracting these may be just as easy as (using a gtar'ism):

	tar --to-stdout -xzf misc.tgz dict | pkg_add -

which would extract the dict object out of the misc pkgset and run it
through pkg_add.  Maybe it's as "simple" as that.  For example:

	% tar tfz misc.tgz
	+SETCONTENTS
	dict
	doc-psd
	doc-smm
	doc-usd
	examples
	man-md
	sendmail-cf

Perhaps the +SETCONTENTS file would differentiate a pkgset from a normal
package, which just has a +CONTENTS file.  Given that (in this proposal)
we just feed the file into stdin for pkg_add, the filename in the
archive can be whatever we want it to be.  Does this seem workable?  All
we'd need is something to build the +SETCONTENT files and the set files,
and (assuming what's said below also happens) something to merge all the
+SETCONTENTS files into a high level directory of what's available.


Now for something completely different:

There's two types of installations as far as how we get the sets,
pkgsets, packages (whatever).  We've either got everything already
(CD-ROMS, NFS, local dirs), or we have to get it (FTP, WWW?).  In some
cases, the "local dirs" option might only include a subset of all
available sets and we probably have to work with that (allowing for
finishing the installation later when all needed sets are available, and
make sure that nothing catastrophic list the base set is missing).

For the "remote" types of installation, it's going to be much easier to
grab the "everything" PLIST (or +CONTENTS or whatever) that does contain
the size info.  This is the sort of thing I see from a sysinst point of
view:

	- user start sysinst
	- user chooses medium
	- sysinst grabs top level pkgset information
	- user selects sets to install (with a default of everything)
	- sysinst calculates total needed space (hmm, including room
	  to download sets before extraction??).
	- user chooses disk(s) and partition sizes (with sysinst
	  verifying that it all fits).
	- sysinst downloads the sets, and extracts them

This type of scenario mandates that we need a top level set list with
the size of all the bits and pieces, that can't be generated at run
time.  Can we all agree on this?


That's all I've got time for now before running to catch a train.  I'll
add some more thoughts later (probably tomorrow).

Simon.