Here's the current design plan for pkg tools. This is not quite organized
yet, and more or less a bunch of ideas.

All packages with emulation are now doing
@exec sysctl -w kern.emul.os=1

we can either add an explicit
@emul os

or a more generic
@sysctl var=value

In both cases, this would probably check the given sysctl value, set it
if needed, and look at /etc/sysctl.conf, advising to add it if needed...

On pkg_delete, we can treat them as yet another shared value, and advise
people to do stuff at this point.

I'm also thinking of adding a construct like
@grep perlre file
for pkg_delete (or maybe @grep/@ungrep pkg_add/pkg_delete ?)
use would be for files like /etc/inetd.conf, where you probably want
to remove/comment out lines when you remove corresponding packages...

In both cases, I'm talking manual changes, just advisory for the people...

There's also an issue with messages I don't know how to deal with yet.
We've got MESSAGE, do we need to add UNMESSAGE EXTRAUNMESSAGE, or do we
simply tag lines in MESSAGE with, say, +-@ for those three states.

There's also some long-planned overhaul there: it's obvious frames like
+------------------
+
+ this is a message
+
+------------------
are NOT a good idea to stick in MESSAGEs. If any decoration is wanted it
should be handled directly by pkg_add/pkg_delete.


Looking at what's left in terms of special cases, I have even less clear
ideas of what to do yet (haven't thought much about it yet...)

- there's obviously a need for @module support: stuff like compiling emacs
files through an @emacs handle should be available once emacs gets
installed. The same mechanism would also handle ghc registration,
xmlcatalog, mktexlsr, apache modules, etc.

There's the issue of retroffitting this stuff for later, e.g., you install
a port with .el files, then later you install emacs. Then you should get
@el support ? a bit icky...

- there are aliasing operations at work: in some cases, one can install
several versions of the same software concurrently (to wit, python), and
creating a symlink if it's not there is icky at best... either be done with
it and explicitly tell the user to choose, or write a way to specify this
correctly.

- sample solved the immediate config file issue, along with making us able
to create directories outside the normal hierarchy. It still misses some
functionality for some ports: in some cases, deinstall needs to be able to
wipe out entire directories and files... interaction between @sample and
@extraunexec rm -rf (or even @unexec) is not very good: files and
directories won't be found as a result. Some ports (web stuff) may need
more extensive facilities, since the port is (more or less) a template
that needs to be copied and entirely customized to be useful.

- fake dependencies are planned out. The way it will work is actually very
simple:
* modify update-plist so that it sorts some files early, e.g., includes,
libraries, *-config binaries.
* insert an @endfake marker afterwards.
* let pkg_add have a `quick' mode where it extracts only the package up to
the end fake marker under a given directory, and so that it creates usable
symlinks (e.g., not DESTDIR).
* update bsd.port.mk to use this.

- a pkg_add -c (check mode) is planned: it will compare a binary package
against installed stuff: md5 checksums, @sample files, @newuser, dangerous
modes.

- pkg_update is still planned for real soon... gonna start on it after the
current sweep of cleaning-up in PLISTs...

Comments welcome.