= pkg_* notes =

Here are some notes for potential future pkg_* development, inspired by
experience developing pkg_patch.

== Package names ==

There is a specific need to strictly separate package names and versions.
Currently, this is done mostly informally, and all package metadata
references combined package names and versions, e.g. "apache-2.2.13", with
more-or-less ad-hoc string parsing to split them.

Keeping them separate would result in at least these benefits:

 * Easier and more strict operations such as dependancy and conflict
   checking within pkg_* tools (e.g. packages do not depend on "apache-2.2.13",
   they depend on "apache", version 2.2.13).
 * Ranged version checks (e.g. package A depends on package B, versions
   X through Y).
 * Easier human-centric interface - users want to deal with strings like
   "packagename", rather than "packagename-1.2.3.45_57".
   
Internal support would have to abstract this into struct plist, etc.

== Compound package names ==

Some packages, for example devel/apr egregiously change their package names
based on configuration options. A typical package built from this port
might be named "apr-ipv6-devrandom-gdbm-db42-1.4.2.1.3.9_1" and the components
can change easily and automatically, depending on build system configuration.
The problem with this is that it makes pure package updating almost impossible
if any of the defaults (components) change.

This will probably need to be enforced via a policy decision.

== libarchive integration ==

Usage of libarchive would remove dependancy on tar which would also remove
the need to invoke pkg_* tools as superuser (needed to preserve file
ownership and attributes), but is extremely inconvenient to use directly
because of the linear nature of archive manipulation.

Any push toward libarchive use in pkg_* will most probably require building a
file system abstraction library which would generate an in-memory filesystem
or a metadata list, which would as a final step be processed through
libarchive. This abstraction will need to support regular-looking file IO
(probably through a FILE* stream) and emulate most of the other unixy
file system syscalls such as mkdir, rmdir, unlink, rename, chmod, chown,
chflags, etc.