Subject: Review for commit: refactoring + package system flavors
To: None <tech-pkg@NetBSD.org>
From: Johnny C. Lam <firstname.lastname@example.org>
Date: 05/28/2006 21:15:25
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
The work is described in my previous email here:
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
* splitting out the configure and build phases into their own
* merging several phases together and remove some more recursive
Please review this work and let me know if any changes need to be made
prior to committing.
-- Johnny Lam <email@example.com>