On Thu, 16 May 2002, Frederick Bruckman wrote:

> The first part of the idea, in brief, is to store these needed
> files in a way that doesn't require any extension to the format
> of ${PKG_DBDIR}, via the mechanism of creating packages "on the fly"
> with reserved names. So when "libfoo-1.0" is deleted, "libfoo-SO-1.0"
> appears, containing only the shared libraries formerly held by
> "libfoo-1.0", while carrying over all the dependencies formerly
> held by "libfoo-1.0". Despite it's dubious origin, this "libfoo-SO-1.0",
> looks just like a regular package to the package tools: the dependents
> reported by "pkg_info -R" are accurate, "pkg_info" over such
> dependents accurately reports their dependence on "libfoo-SO-1.0",
> and "pkg_info -L" lists the (few) files it contains.

I generally like this.  As a user of some slower machines (my main
computer I type in front of is a sparc IPX) the current upgrade procedure
has been more than painful, its just not practical.  My installed pkgs
probably represent 2 weeks of compiling on this box so your proposal is
especially cool for me!

I'll try and make time over the next week or so to read over what you've
coded up.  Thanks for working on this.

> 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.

-Dan