On Wed, 30 Sep 1998, Jonathan Stone wrote:

 * 
 * But what pkgsrc does is not necessarily the right precedent, here.
 * Because this isn't the pkgsrc system!

It could be.  Perhaps we could merge the desired functionality into
pkg*.

It would beat having two almost identical toolsets floating about.

 * 
 * Perhaps you're overlooking that if we do an OS upgrade of a pre-pkgset
 * installation, there _is_ no pkg info for the old base-system
 * install-sets that's being upgraded?  we dont have a pkg database with
 * the contents of the `previous' release, because it wasn't a package
 * then!

Stupid chicken's gotta lay the damn egg sometime.

 * Pkgs are the pkgs we know and love. (maybe better size info would be
 * nice, but whatever.)
 * 
 * Pkg-sets are (IMHO) handled by a slightly different tool, the install
 * tools. From the install-tool end of things, the whole reason we're
 * using sets of pkgs is so users can decide install all of a set, or to
 * select individual pkgs from a set.  

This shouldn't need to be the case.

 * 
 * That means sysinst (or replacement) needs to parse the pkg-set
 * contents, and either pop up a menu of what's in it and let the user
 * toggle which ones get installed; or iterate through them asking the
 * user "install: yes/no?".  I don think we can do that as part of the
 * current pkg tools, not least because the pkg system doesn't _do_ that,
 * AFAIK.  (What does it do with a pkg file which contains another pkg as
 * contents? Install recursively, or plop the pkg file into the target
 * filesystem?) And the obvious hook, the pre-install scripts, arent
 * viable because, for the base system, we have no guarantee that "base
 * system" commands called by those scripts are already installed!

Well, no and yes.  You don't install into the same root directory
that you're installing from, as a rule; if you do, chances are that
you have the same set of tools there that you need to run the scripts.

Just make it a rule of thumb not to stick anything too terribly
outlandish into the pre-install scripts for the "base" pkg.

FWIW, and having had to design an installer from the ground up
(it was a failure, BTW -- too project-specific, but I did learn
a hell of a lot regarding software design and appreciation for
software installation tools), having pkg-sets and pkgs too disparate
will only do us disservice in the long run; pkgs should be disintegrable
into pkg-sets, with the ability to install on more finely-grained
constraints depending on experience/willingness to frob bits here and
there.
				--*greywolf;
--
After 5 PM please slip brain thru slot in door.