On Thu, 16 May 2002 mcmahill@mtl.mit.edu wrote:

> > In the tarball, there's also a man page for a little utility I'm
> > working on, "pkgorder", to spit out dependents and dependencies in
> > order. I originally thought it would be necessary to make "pkg_hack"
> > work at all, but now I think it's separable, and not absolutely
> > necessary.
>
> you may have looked already, but mk/bulk/tflat does some processing and
> flattening of dependencies.  tsort(1) does dependency sorting,
> mk/bulk/pre-build uses it, and pkgtools/cdpack does some dependency
> processing on a set of binary pkgs.  tflat and cdpack are written in awk.

Yes, letting "awk" generate pairs for "tsort" seems to be the most
efficient way. With that, you can sort all 2000-odd packages in
seconds. Once you have the complete database, which you have only have
to generate once for all machines, the options can be parsed and lists
calculated in no time at all. The awk shellsort as in
${_RECURSE_DEPENDS_DIRS} doesn't scale well -- if you feed the script
just a few dozen packages in the reverse of their final order, "gawk"
invariably dumps core.

The purpose of "pkgorder" is generate lists of packages to upgrade
or otherwise operate on. So for example, to upgrade "png" and all
installed packages that depend on it, you might do

	for p in $(pkgorder -r -I graphics/png)
	do
		pushd /usr/pkgsrc/$p
	done
	while true
	do
		(make package && make clean) && popd || break
	done

with the added benefit that if something goes wrong ("if" -- hehheh),
you're left in the directory with the broken package (to fix it).

Frederick