Alistair,

What you say sounds fine to me.  I do think some kind of speed is
important, though. Pragmatically, sysinst is a real nightmare to test,
and historically it's been the last thing to get worked on during
releases.  We simply _cannot_ let that happen with a merger of the
release(7) sets to be pkg-oriented; we cannot change the pkg_tool
format during a major release BETA, for example.

The way I see it, Jim and Simon and I havea all been saying this:

  1. sysinst has a real requirement for "containers" of pkgs, which
     we've agreed to call pkgsets. this  is a real requirement,
     it's not really a negotiable one. meta-pkgs don't meet it,
     because when installing from a non-Unix box (DOS, mac, amiga,...)
     the user has no way to check dependencies (no pkg tools
     to extract them, no tsort to check them, etc.O

  2. The sensible approach si for the pkg tools to understand pgksets.
     That means both tools can use them.  There's an obvious
     synergy in having the pkg_* tools be able to do post-install
     addition of sets the user initially skipped (e.g., lack of disk
     space to stage them during install).

     
  3. We install-side people have described the key functionality
     that we need and suggested  2 or 3 different ways the pkg_*
     tools could be extended to do this.

  4. It's become apparent that we'd be even better off  if sysinst
     could just _invoke_ pkg_* tools to do all manipulation of pkgsets;
     list contents, do full extract, do partial extract.
     That way only one toolset knows about the pkgset format; the
     pkg* people can rev it as you please independent of sysinst.
     (I had thought of a librrary, but  is already designed to
      fork off existing tools and use them. everybody wins if we
      can do that with pkg_* toosl for pkg sets.)


  5. Some pkg people are  verymis-understanding this request,
     in a number of diferent ways:

        a) that pkg dependencies (meta-pkgs) are an adequate
           solution for install sets.  They clearly aren't.

        b) as if we're saying the third-party pkgs will have to
           use pkg sets. That is not true; it's entirelyup to you
	   pkg people to decide that,

  	c) that the introduction of pkgsets for install tools
	   will force duplication of of multiple coples of
	   precompiled pkgs where we now use pkg dependencies.
	   That's crazy; see (b).

	d) That the install-side people are forcing two
	   variant formats and needlessly-diverging toolsets
	   to handle them.  That's crazy;  to consider any kind
	   of `container' mechanism is the only thing driving that.


[I hope we can all show a little more maturity and engineering sense,
and work together to solve this problem.

Alistair: I am reluctant to drag you into this if you don't want to
say anything.  But at this point, I'm going to ask for one thing.

Can you commit, in principle, on behalf of the pkg people, to
providing _some_ form of `container' mechanism which the pkg-tools
understand; either

	    a) via a @pkg tag in +CONTENTS
	    b) via +SETCONTENTS instead of +CONTENTS in a pkg
	    c) a new `pkgset' format -- a tarball with a contents file
	       -- and a new `set_add' command
	    c) any alternate mechanism of your design (you're the experts
	       here after all!)

which need not be used _at all_ by the existing pkg system or pkgsrc,
but which sysinst can rely on to implement pkgsets for our next release?