[Joe Orton]
> I think the correct answer is that any application which links against
> libsvn* must also link directly against (i.e. have a DT_NEEDED for)
> libapr. The Subversion API does not isolate applications from APR ABI
> changes, so this doesn't seem unreasonable - <app which uses SVN> has a
> direct dependency on the APR ABI version; so app needs a DT_NEEDED for
> the libapr SONAME.
OK, so can you tell me what happens on Fedora if I do the following?
1) Compile an application using libsvn-linked-to-apr-0
2) Upgrade subversion to a build that uses apr-1
3) Try to run the application
Debian users expect this to Just Work, and part of my job as a library
maintainer is to accommodate use cases like this one. Manipulating
SONAMEs is a large part of this. Library maintenance is harder than
regular app maintenance precisely because we have to think about these
things.
Here are the possibilities that I can think of:
1) The application will find an old libsvn and apr-0 at runtime, and
will work normally. This requires that libsvn-with-apr-0 and
libsvn-with-apr-1 coexist on the system, and that the runtime linker be
able to tell them apart. To do this, the runtime linker needs to see
two different SONAMEs.
2) The application will fail to run because apr-0 is no longer
installed at all. This assumes apr-0 and apr-1 cannot coexist on
Fedora. If apr-0 and apr-1 can't coexist, it also implies that moving
from one to the other requires rebuilding *all* apps (packaged or
local) that depend on it, all at once. Such a forced transition is
considered very bad form on Debian.
3) The application will run with a new libsvn-with-apr-1 and thus will
indirectly load both apr-0 and apr-1 when starting up. It will later
crash or misbehave, either because of symbol confusion between the two
versions of apr, or because of an ABI mismatch with libsvn (all uses of
apr_off_t). If you are very lucky and the app doesn't use apr_off_t
anywhere, it *may* work normally.
Those outcomes are in decreasing order of preference. 2) is better
than 3) because at least the problem can be unambiguously determined,
but Debian developers and users would be quite unhappy with either.
> Making every library SONAME be a product of the exported ABI version
> of every dependant library would get quickly unmanageable.
Only dependent libraries that affect the ABI of your own library. Many
such changes don't affect you. This, by the way, is why Debian libtool
tries not to force an application to link the whole chain of dependent
libraries directly. Doing so would make library transitions much less
agile, because of artificial version dependencies that the app should
not have to directly care about.
> You'd also have to embed the apr-util ABI version in the SVN sonames;
> and the apr-util ABI version must also probably embed the OpenLDAP
> ABI version because of the apr_ldap.h mess; etc etc.
The aprutil version bump matches the apr version bump, so I see no need
to embed that separately. I know they are separate libraries, but it
seems reasonable to treat them as a unit, until such time as I have a
need or desire to upgrade their uses independently.
As for aprutil being affected by libldap, it is the responsibility of
the Debian aprutil maintainers to ensure the same thing I'm trying to
ensure. If they have to force a SONAME bump in order to incorporate
some new LDAP client library, they will do so. Then I have the option
of following them, or sticking with the old library version. But since
libsvn does not use LDAP, I can't imagine why the LDAP interface change
would trickle down into the libsvn ABI. Thus *my* users would still
not be affected (unless they also use LDAP independently of using
libsvn, of course.)
> Yet there's absolutely no practical gain to adding all this
> complexity: when you want to update to an APR package which has a new
> ABI, you still have to update exactly the same set of packages.
Only if you assume that all library ABI changes propagate all the way
down the chain to affect user apps. In many if not most cases, this is
not true. As an example, apps that use libsvn_fs have no need to link
directly to libdb4.x, and as far as I can tell, no need to care which
version of Berkeley DB was used to build Subversion. The
libsvn_fs_base ABI shields the app from having to know. So rebuilding
Subversion against a newer BDB may require migrating repositories, but
will not require recompiling applications.
By trimming dependencies down to what an application uses _directly_,
we avoid lots of cases of forcing users to recompile (or forcing
maintainers to upload recompiled packages) needlessly.
> The Debian libtool patch which Justin mentions is certainly related
> to this: libtool will by default ensure that the libapr* dependency
> is leaked upwards to any application which links against libsvn*.la.
I fail to see how that helps anything. If an app links to apr-0 but
libsvn uses apr-1, it's not like this will catch the problem, unless
you remove apr-0 from your system so that the app will fail to start.
Peter
Received on Sat Mar 11 23:28:35 2006