libsvn SONAMEs and APR

Debian subversion builds will soon be moving to apr 1.2, in lockstep
with Debian apache2. (Because of mod_dav_svn, we have no choice.) We
know this will occasion an ABI change to libsvn, so this requires
changing the embedded SONAMEs of the libraries. (See footnote for a
quick introduction to SONAMEs.)

I note that subversion currently has no particular notion of library
versions - which I suppose is OK since you're committed to never
changing the ABI incompatibly - but it's probably better to be
explicit. Anyway, libtool generates its own default SONAMEs:

  $ objdump -p /usr/lib/libsvn_client-1.so.0 | grep SONAME
    SONAME libsvn_client-1.so.0

I'll need to adjust this in some way, to denote the ABI change caused
by the new apr. I'll do it myself on Debian if I have to, but I'd
prefer to avoid this, as it'll create a gratuitous incompatibility
between Linux distributions. E.g., if Fedora also decides to build
subversion 1.3 with apr 1.2, our binaries won't work on Fedora, or vice
versa, unless they happen to make the *same* change to the SONAME
strings that I do.

Would you consider accepting a patch to make SONAME handling explicit
in the Makefile, and also make it sensitive to apr version? Would you
consider this for 1.3.1 or 1.3.2? I'll try to prepare and test a patch
in the next day or two.

Thanks,
Peter

[*] Quick introduction to the SONAME feature: it's a free-form string
embedded in an ELF-format library. A binary linked to the library
copies the SONAME field so that it can look for that exact string, as a
filename, at runtime. (The filename will be a symlink to the library,
placed in /usr/lib or /usr/local/lib or similar.) If an ABI changes
incompatibly, the SONAME of the library must change as well, so that if
you run an old binary, it won't pick up the new, incompatible library -
either it finds a copy of the old, compatible library, or it gets a
runtime error and quits. The SONAME typically takes the form
"libfoo.so.N", but the only thing that really matters is that it be
unique for a given library ABI. The term "SOVERSION" seems to mean the
part of the SONAME that changes between ABIs, but it's not a terribly
well defined term so it's best avoided.

SONAMEs aren't intended to solve the problem of a new binary picking up
an old library and trying to use new features which are missing.
That's a *compatible* ABI change to the library. The *incompatible*
change I'm talking about in this message is the change of apr_off_t
from 32 bits to 64 bits on 32-bit platforms, which affects libsvn's ABI
as well.