Hi all,
since I don't think that most of you follow the netbsd-soc project, let
me quote one of entries in the documentation I'm writing. I want to
expose this to the greater audience to device whether I found all the
important issues.

>>>
ABI compatibility

For updating packages the system has to ensure that the new package can
replace the old version without breaking the packages using it. This
means that the file formats and especially the shared libraries of the
new version must be compatible to the old version. For this, packages
express explicitly to which versions they are ABI compatible.

A direct update is allowed only if the new version announces its
compatiblity with the old version and fulfills all dependencies of the
old version. The system should record all provided shared object names
of ELF binaries in the package, or similiar information for other
executable formats. This information can be used to assist maintainers
during the process of updating the build description. 
<<<

When updating a library the maintainer currently checks whether any
shared library has a major version bump or other incompatibilities
occured. In that case, she would alter the BUILDLINK_ABI_DEPENDS pattern
and recursively bump all depending packages. When a user now wants to
update, she would also install the newer revisions of all the other
packages.

This is a major downside though: the old revision would still
be installable. This is were the ABI compatibility entry of the proposal
kicks in. It creates a reverse conflict (the depending package gets a
conflict added the dependee) and prevents the installation.

This scheme has the major advantage of requiring only BUILDLINK_API_DEPENDS,
since the build version of the package is recorded and can be used to match the
ABI for compatibility.

Two situations exists, which I haven't fully thought out or exploited
yet.

(1) An ABI conflict is detected. Should this result in a more
intelligent selection algoritm (conflict avoidance strategies)? I don't
think we can provide a universal solution. Anyone who tried Debian with
a mix of release repository and Sid knows what I am talking about.

(2) A package gets renamed. The ABI compatibility could be used to
handle this case semi-automatically, given a reasonable
intelligent repository (you don't want to search 6500 packages by hand).

Joerg