--- a/doc/packaging.txt	Thu Apr 14 12:41:18 2011 -0700
+++ b/doc/packaging.txt	Thu Apr 07 15:37:10 2011 -0700
@@ -29,11 +29,11 @@
             |
             v
     dependencies resolved
-    (.../{component}/{build-dir}/manifest-$(MACH)-{component}.resolved)
+    (.../{component}/{build-dir}/manifest-$(MACH)-{component}.depend.res)
             |
             v
     manifest validation
-    (.../{component}/{build-dir}/manifest-$(MACH)-{component}.linted)
+    (.../{component}/{build-dir}/.linted-$(MACH))
             |
             v
     publication manifest
@@ -48,7 +48,7 @@
     automatically from the data encapsulated in the component Makefile, gate
     transformations, build tree, and packaging tools.  This includes actions
     for license information, some path related attributes, legacy actions, 
-    non-discoverable dependencies, user, group, driver, and others.
+    non-discoverable dependencies, users, groups, drivers, and others.
 
     Actions that are associated with objects that are specific to a single
     architecture should be tagged with a 'variant.arch' attribute specific to
@@ -85,7 +85,7 @@
     The mogrified manifest and the prototype install tree are passed through
     pkgdepend(1) to generate a set of dependencies for the package content.
     These dependencies are only those that "pkgdepend generate" can determine
-    on it's own.  Additional dependencies that can not be automatically
+    on its own.  Additional dependencies that cannot be automatically
     determined by pkgdepend(1) should be placed in the canonical manifest.
     Statically defined dependencies should be described in a canonical manifest
     in an unresolved form (ie. the form generated by "pkgdepend generate").
@@ -102,15 +102,20 @@
     package(s).
 
 Dependencies Resolved
-    The manifest with unresovled dependencies is passed through pkgdepend(1)
+    The manifest with unresolved dependencies is passed through pkgdepend(1)
     again to resolve dependencies against the package repositories.  The
-    result is a manifest that is suitable for publication.
+    result is a manifest that is suitable for publication.  All these
+    manifests are processed together in a single step, which is more
+    efficient than resolving dependencies in each manifest separately.
+    While each manifest ends up with a .depend.res copy in the build
+    directory, the umbrella dependency resolution target is
+    {build-dir}/.resolved-$(MACH).
 
 Manifest Validation
     The resolved manifest(s) and prototype install tree are passed through
     a set of validations.  This includes running pkglint(1), comparing the
     manifest content to the prototype install tree, and validation of the file
-    content of the prototype install tree.  Any anomolies are reported.
+    content of the prototype install tree.  Any anomalies are reported.
     Content validation is performed by extension to pkglint(1) in
     $(WS_TOP)/tools/python/userland-lint