Can we agree on terminogoly here?

     * meta-pkg: a valid PKG which contains pkg dependencies on
       (or for short, "pointers to") other packages, possibly
       in addition  to realcontents of its onw.
       Does not actually contain copies of  other packages
       on which it depends..

     * pkg-set:   sinlge file which contains copies of several pkgs.
        The package, collectively, add up to the current contents
	 of the "base", "comp", "xbase",  or other .tgz tarballs.

I think thats what Jim and I are using.

I think meta-pkgs are Right Out. Once you buy into pkgsets instead,
and accept that pkgsets arent quite the same as normal pkgs, then ts
of the answers just fall out.  Jim and I seem to've got to the same
place, anyway.


[meta-pkgs versus pkg-sets]


>Not really. Right now you can query the pkg's PLIST (+CONTENTS file) with
>"pkg_info -f", and adding some option to only print the @pkgdep lines
>shouldn't be to hard either (or to dig them out from some program that
>uses that kind of inforamtion).

>With that kind of information, you can descent again into a pkg and get a
>list of all the needed dependencies. (Right what "make
>print-package-depends" does in source now :).

Nope.  You assume stuff (like network connectivity or easy/automated
access to depended-on pkgs).  When this came up under the guise of
"absolutely necessary sysinst improvements" pathat was vetoed by
several developers:

     #1: split floppy images.   Its easier to properly order a set,
        or a small number of sets, than to separately order
	dozens of little packages.

     #2: pre-loading the pkgsets to a "native" OS filesystem.
	 E.g., to install on a laptop with PCMCIA ethernet which
	  doesnt work with the generic kernel.  Copy to DOS disk,
	  mount that via msdosfs, and install from local OS.
	  Or even to take on a visit to a friends' to install NetBSD,
	  or for a trip to a remote site.
	  Its much easier to handle a few sets than many.

     #3: Other concerns about the number of files needed to
         do the "base: install.  E.g., when doing a one-off manual
        "mirror" -- e.g., as a pre-installation loading through
	 a firewall onto an internal FTP or NFS server, or as
         preparation for #1 and #2.

Once you have a usable system installed, have an Internet link or a CD
full of pkgs (and perhaps a fireall-aware ftp client), walking the
contents of a meta-pkg and slurping down all the depended-upon pkgs is
probably OK.


But from install/sysinst perspective, tfha just is _not an option_:
see 1-3 above).  (If the developers, Core, portmasters, otherwise, who
spoke up on this in April want to change their minds, please speak up now!)


I dunno, Hubert. Maybe a big part of the difference in view here is
that its _so_ much easier to recover from a mistake once you have a
base system up and running. Then, it's reasonable to automate this via
the pkgsrc Makefiles, or pkg_install ftp://... , or whatever.

But when all you have is the install floppy and missing a component
means rebooting DOS and refetching, or even scheduling a second visit
to a friends', or even another trip, its just not on.  Not just me,
I'm merely the poor sod working on sysinst at the time, who tried to
record it all. These were brought up as real, serious objections.