Hi all,
here is the initial proposal for PLIST entries.

(1) Normal files
- path name relative to PREFIX
- file content is associated (e.g. in the binary package or the file
system)
- meta data consists of:
  * owner, group, permissions
  * checksums (algorithm, value pairs, default SHA1 and RMD160)
  * modification time
  * optionally triggers

(2) Normal directories
- path name relative to PRFIX
- reference counted
- meta data consists of:
  * owner, group, permissions
  * NO modification time
  * optionally triggers

(3) template-based files
- path names can be either relative to PREFIX or absolute (e.g. VARBASE)
- meta data consists of:
  * owner, group, permissions
  * template name ("/dev/null"  assumed if missing)
  * optionally triggers
- on installation time, the template is copied to target name, if
missing. alternatively an archived version might be restored. on
deinstallation time, the file is either removed (when unmodified),
archived (modified) or left in place.

(4) template-based directories
- path names can be either relative to PREFIX or absolute (e.g. VARBASE)
- meta data consists of:
  * owner, group and permissions
  * owner, group and permissions for files under this directory
  * owner, group and permissions for subdirectories
  * template name (empty directory assumed if missing)
  * optionally triggers
- similiar to (3), but considers the entire subtree as configuration
item. useful e.g. for Apache which uses multiple subfiles by default.

(5) Unmanaged files
- like (3), but will always get removed with the package

Rationale:
----------
(1) should go without further comments, it is pretty much what we
already have. The addition of more metadata helps to detect modification
and use pkg_install as a light-weight IDS.

(2) allows creating directories with special permissions, they don't
create conflicts as long as the owner/group/permission set is identical.
It will be used internally by the system to keep track of implicitly
created directories. This means no more @dirrm.

(3) and (4) are pretty much what the current config file framework
already provides. I want to make them a first class citizen of the PLIST
for a number of reasons. It simplifies detection of files which should
not be there or which can't be associated with a package. It should be
possible to find the package which provides a file in PREFIX no matter
what. Making them first class citizens also allows better integration
with the frontend tools and other adminstration programs.

(5) is finally meant for all the noisy caches and registries, currently
managed by hand. I'm not sure if we also want to have a directory
version though (gnome-mime?).

Joerg