* Add scripts to generate a manifest from a NetBSD distribution or release.

* Decide whether and how to distribute manifests.

* Merge support from BUILD-NetBSD to freshen all kernels in / to
  INSTALL-NetBSD.  This is typically only needed on Xen machines that
  want to have GENERIC, XEN3_DOM0 and XEN3_DOMU in /.  Then drop
  install support from BUILD-NetBSD.

* Consider some mechanism for adding a file to the database with
  upstream's md5, in cases where the file exists in /etc but with a
  different hash.  That will cause later removal to show as a
  conflict, rather than a file which does not exist and is not in the
  database, and thus allowable to install from upstream.

* Rethink if every file in upstream should be in the databsae, with
  upstream's hash.  That will cause all files that don't match to
  appear as CONFLICT, vs unregistered.  Perhaps extend the database to
  have a "marked by admin as ok to be different" flag.

* Extend to 3-way merge by storing the merge base and perhaps using it.
  (Think hard about whether we are reinventing git, but really this is
  still per-file and lightweight.)

* Make it possible to mark directories as managed, but without
  md5sums.  If such a directory is empty and does not exist in the new
  tree, it is removed.

* Add --verbose (-v) option to --update to print messages that are
  easier to understand.

* Printing the "MANUAL" messages is not terribly useful.  Perhaps they
  should only be printed if a --verbose option is specified.

* Consider removing known non-config files (e.g., /var/log/messages)
  from the etc sets extracted during BUILD-NetBSD and INSTALL-NetBSD.
  (Really these files should be removed from the etc sets, but this
  would be a useful workaround until that happens.)

* Add tests to ensure that file/directory ownership, permissions, and
  access/modification times are preserved when installing a
  new/updated config file.

* Handle symlinks specially.  Right now, if a symlink points to a
  regular file it is treated as if it was a regular file.  If it
  points to a non-regular file (e.g., directory or FIFO), then it is
  ignored.  Instead, a symlink should be managed as a special type of
  file whose contents are the link destination.  For example, the
  database entry could contain something like:
      link:<md5_of_readlink()_value_goes_here>

* Handle other non-regular files.  Right now, INSTALL-NetBSD unpacks
  the etc and xetc sets to /usr/netbsd-etc instead of /.  If either of
  these sets gets a new special file (e.g., FIFO or device) then the
  special file will not be installed in the live filesystem.  This
  could be handled by always installing special files directly to /
  (overwriting if the target already exists), or they could be managed
  through etcmanage via special hash strings.  For example, the
  database entry for a block device file could contain something like:
      block:<major>,<minor>
