On 3/10/06, Peter Samuelson <peter@p12n.org> wrote:
> 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:
I'm not sure why we need a SONAME for Subversion or APR. 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? In
other words, if a FC Subversion 1.3 binary tried to run on Debian,
shouldn't it be looking for libapr-0.so? (If it linked against APR
1.x, then it's safe to assume LFS.)
Are you saying that there may exist a hypothetical APR 1.x library
that doesn't support LFS? If so, that's an option that the packager
had to explicitly override - why are we having to worry about that?
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. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 11 00:32:00 2006