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

I hope 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

[snip rest -- i agree with Simon's take]

Sure.  All I'm doing is observing that, in fact, you could do the same
by-hand installation of a pkg file. (or at least ive done that with
xfre86 pkg files, back in 1.2, before the pkg tools were in our formal
releases).  

And observing that if a user initially skipped whole sets and wanted
to add them, it might be convenient for the user to use pkg_add (or a
replacement/extension -- set_add?) which automated the process, maybe
updating a `black-box' recording of sysinst options, too.

To me, they look similar enough that maybe the pkg tools should
support `containers', too.

sorry to labour the point, I just want to make it clear where I'm
coming from.


I'm just guessing, but it seems like maybe the pkg side of the house
live in a world where it's OK to assume you always have FTP
connectivity to (or a CD of) a full set of release/pkg binaries.
For pkgsrc, thats probably OK.

For the install tool, thats definitely not OK.

>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?

Rephrase: the size cant easily be generated at install-time, without
doing a second pass.  But the unpacked size of each pkg can be
computed fairly trivially at pkg-build time, and the size of all pkgs
in a set can be kept and added together at set-build time.

Yeah, I hope we agree.