Subject: Re: PROPOSAL: NetBSD System Packages
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Gandhi woulda smacked you <email@example.com>
Date: 10/01/1998 01:57:37
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
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
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
After 5 PM please slip brain thru slot in door.