[Justin Erenkrantz]
> I'm not sure why we need a SONAME for Subversion or APR.
Because that's how runtime linking on ELF platforms works.
I don't know how all OS platform maintainers feel, but on Debian, we
don't assume that when you upgrade one library you will be willing to
recompile everything that depends on it. We do whatever we can to make
sure your system, and all the binaries on it, continue to work. The
ELF SONAME feature, when used properly, makes this job a lot easier and
more reliable. Thus in Debian we have a policy of always using it
properly - not doing so is considered a bug.
As for libsvn, we have to use the same version of libapr that apache2
uses, because mod_dav_svn must link to libsvn and it must work with
apache2. This requirement drives the version of libapr we link to.
Now we've got an incompatible change coming up where we'll need to
switch from apr 0.9 to apr 1.2. Normally such a thing would be no big
deal, but in this case it means libsvn's own interface changes
incompatibly.
Beyond the Debian policy of using the library SONAME as it was meant to
be used (i.e., to uniquely identify a compatible ABI), the practical
reason we have to change it now is to allow the old and new libsvn's to
coexist on a single system. Old binaries compiled before the change
will use the old libsvn, new binaries compiled after the change will
use the new one. Thanks to the SONAME feature, this works pretty much
automatically, so long as you change it when you need to change it.
(The other thing we have to do is arrange for the old and new packages
to coexist, but that's easy enough, and outside the scope of this
discussion.)
> Shouldn't Debian be linking against APR 1.2 instead of 0.9 now? Why
> wouldn't the standard library dependency code catch this mis-match
> then?
First of all, an app that links to libsvn won't necessarily recursively
link to libapr 0.x or 1.x. That's required on some platforms but not
on ELF, since recursive runtime linking is easy and done by default.
Second, if an app does link to both libsvn and libapr 0.x, and then
tries to run with a libsvn that pulls in libapr 1.x, it may or may not
actually be caught as a runtime-link-time error. It's not actually
forbidden to link (indirectly) to two or more versions of the same
library. More likely, you'll get mysterious seg faults as the wrong
symbols are used in the wrong places. If you avoid the seg faults,
you'll also get madness where client code and library code don't agree
on the size of svn_off_t when it appears in structures or stack
parameters.
2a) In case you were assuming otherwise, libapr-0 and libapr-1 can both
be installed on the same Debian system. Some apps will use one, some
will use the other, and thanks to SONAMEs this works seamlessly. So in
any case, you can't detect which libapr is used for libsvn just by
seeing whether libapr-0 or libapr-1 are available. Commonly they both
will be.
If linking to libapr 0.x vs. libapr 1.x didn't change the exported
Subversion ABI, the SONAME of libsvn wouldn't need to change, and we
wouldn't be having this conversation at all.
> Are you saying that there may exist a hypothetical APR 1.x library
> that doesn't support LFS?
No.
> IIRC, the Debian patch to libtool overrides the GNU linker DT_NEEDED
> flags and just might cause this specific problem - as the binaries
> will ignore accompanying libraries and use only installed libraries
> in /usr/lib. If the case is that Debian didn't screw with libtool we
> wouldn't have this problem, then I'm not sure why we need to fix
> their brokenness.
You seem to have some bitterness in your heart toward the Debian
libtool changes. (: But the SONAME issue, though it also deals with
libtool, has nothing to do with that particular change.
I hope this message clarifies some things. If not, I'll try to clarify
further as needed.
Peter
Received on Sat Mar 11 00:58:40 2006