I've uploaded a tarball of the work that I've done in refactoring
several phases of the pkgsrc build workflow out of bsd.pkg.mk and into
separate modules:

	http;//www.NetBSD.org/~jlam/flavor.tar.gz

The work is described in my previous email here:

	http://mail-index.netbsd.org/tech-pkg/2006/05/21/0001.html

I've done a first pass at separating out places where we make assumptions
about the package system flavor, mostly either because we directly
use the pkg_* tools, or we make assumptions about the package meta-data
directory, or we directly manipulate the package meta-data files.
Those parts that I've isolated are all collected into pkgsrc/mk/flavor/pkg.
I've also removed several unnecessary instances of recursive make calls
and split out the "reduce-depends" functionality into a separate script.

The design I chose was that the various install, package, etc. modules
would define default targets and variables that may be overridden in
files from pkgsrc/mk/flavor/pkg.  The default targets would do the
sensible thing of doing nothing, and pkgsrc infrastructure would rely
on the appropriate things to be defined in pkgsrc/mk/flavor to do the
real work.  The pkgsrc/mk/flavor directory contains subdirectories
corresponding to each package system flavor that we support.  Currently,
I only have "pkg" which represents the pkgsrc-native format.

There is more work I want to do, but I want to commit what I have now
since it is stable and functionally replaces parts of the current
pkgsrc infrastructure.  The immediate follow-up work entails:

    * rewriting the pkginstall framework to provide a standard pkg_*
      tool to perform the actions, and allowing a purely declarative
      file per package to describe what actions need to be taken at
      install or deinstall time; and

    * rewriting the buildlink3 framework to not assume the use of
      the pkgsrc pkg_* tools.

This would pave the way for a complete re-write of the pkg_install
tools without tying ourselves to either the interface of implementation
of the current pkg_install tools.  The longer-term follow-up work
includes:

    * splitting out the configure and build phases into their own
      modules; and 

    * merging several phases together and remove some more recursive
      make invocations.

Please review this work and let me know if any changes need to be made
prior to committing.

	Thanks,

	-- Johnny Lam <jlam@pkgsrc.org>