On Sat, Mar 11, 2006 at 04:27:59PM -0600, Peter Samuelson wrote:
> [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.
You cannot expect the above to work at all - you can only expect it to
work when the application is rebuilt against apr-1. The application has
a dependency on both the SVN ABI and also on the APR ABI.
> 2) The application will fail to run because apr-0 is no longer
> installed at all.
Correct if the application does have a DT_NEEDED for the apr-0.x soname,
and the apr-0.x package is removed when upgrading to apr-1.x (as would
normally happen).
> 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.
We could support that in Fedora, and would if there were a substantial
number of third-party APR-based apps that people used; but there aren't
many such apps, so we don't. But this is just distro policy and is not
really relevant.
> 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.
Correct if the application has the DT_NEEDED for apr and the user
decides to have both apr-0.x and apr-1.x packages installed. Even if
the SVN sonames are munged the user will be able to shoot themselves in
the foot in exactly this manner.
> > 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.
The APR-util ABI could be changed without changing the APR ABI, there's
no enforced lock-step there. svn_base64_from_md5 exposes a dependency
on APR_MD5_DIGESTSIZE, which is defined by the APR-util ABI. This would
be simple to avoid, 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.
That's not logical; I'm not talking about the general case, I'm talking
about this specific case. It is true for Subversion and APR; if you
rebuild Subversion against a version of APR with a different ABI, you
must to do so for all apps linked against Subversion too.
You seem to imply this is not the case. It's true not only because of
the exposed types like apr_off_t, but also because SVN-based apps are
required to use APR interfaces directly, from apr_initialize(), to
pools, to apr_hash_* and so on. The APR_OS_START_USERERR definition is
another place where SVN consumers would be affected by an APR ABI
change, since it would change all svn error codes too.
> > 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.
It ensures that there is a dependency between application and the APR
ABI version, as would munging the SVN soname as you propose.
> 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.
That's a different problem, and one which cannot be solved by the
runtime linker; merely changing the SVN sonames doesn't help.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 12 17:04:31 2006