[Justin Erenkrantz]
> We have explicitly decided in the past that the binary compatibility
> only matters for the Subversion code we distribute - not any of the
> dependencies or how they present themselves in the Subversion ABI.
I don't think there's much more I can say that will convince you that
your approach is a problem. I'm interested in smooth upgrades for
users currently on apr 0.9, which is what subversion 1.3.0 ships with.
You're interested in smooth upgrades for users who already switched to
apr 1.x and already had to recompile all their apps, _and_ who intend
to remove their old libsvn_* files after compiling the new ones, even
if the names didn't overlap.
So let me instead recommend that you document this: if a user upgrades
apache to 2.2 and wishes to use mod_dav_svn, she must not only
recompile mod_dav_svn (no avoiding that, you actually have to recompile
_all_ apache modules) but she must _also_ recompile all apps which use
the subversion libraries, whether or not they have anything to do with
apache. And, that you don't consider this a binary compatibility
problem, even though you chose long ago to tightly couple the
subversion API/ABI to the apr API/ABI.
I think it's only fair for users to know they will have to do this, and
that you disavow any responsibility for mysterious seg faults if they
forget.
Meanwhile, I hate to have to break binary compatibility between Debian
and other Linux distributions, but I'll do it anyway. I have no
choice. I would face a lot more angry users (and fellow developers)
for breaking applications compiled on Debian than for breaking Fedora
RPMs people try to install on Debian.
Peter
Received on Mon Apr 3 22:13:14 2006