pkg
ELF (AND MAYBE JAR) DEPENDENCY HANDLING

ELF files give us ISA information, required libraries with versions, and
potentially provided interface versions.  This latter information is
missing from a large set of libraries on OpenSolaris, built without
versioned interfaces.

It seems that an ELF file, on upload, can be tested for its ELF
dependencies, and that these files in turn can be tested for presence.
If any of the latter file's revisions provide versions, then these can
be tested and translated into a minimum package requirement for the
package containing the introduced ELF file.

We always want the latest version surface, so we don't want to send a
new header file without the corresponding ELF objects its changes caused
to be generated.

It seems that ELF differences are only useful for determining whether an
incoming transaction is significant.  For instance, RE delivers a group
of change that actually contains no change to the non-ELF files, and the
change to the ELF files is non-ELF significant.  In this case, perhaps
the delivery should fail/warn.

XXX Can we do something similar for JAR files?  Tasting JAR files is
outlined in $SRC/cmd/file/file.c:zipfile(), since a JAR file is a zip
file with extra header information. [1]

XXX Can we do something similar for Perl or Python (or any language with
internal versioning statements)?

XXX There's really no way to tie the kernel to libc in the current
system, or in pkg(1M).  Should we be adding a simple signature, or
reusing library versioning, or must it be left to a human (expressing it
via pkg(1M) dependencies)?

[1] Sun Microsystems, Inc., JAR File Specification,
    http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html