[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4 configure.ac

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 21 Jun 2011 19:41:58 +0100

Greg Stein <gstein_at_gmail.com> writes:

> On Tue, Jun 21, 2011 at 14:15, Philip Martin <philip.martin_at_wandisco.com> wrote:
>> Greg Stein <gstein_at_gmail.com> writes:
>>> On Tue, Jun 21, 2011 at 11:16,  <philip_at_apache.org> wrote:
>>>> Author: philip
>>>> Date: Tue Jun 21 15:16:07 2011
>>>> New Revision: 1138040
>>>> URL: http://svn.apache.org/viewvc?rev=1138040&view=rev
>>>> Log:
>>>> Support building with APR 2.0.  Berkeley DB detection doesn't work.
>>> I'm not entirely sure that we want to allow this.
>>> We provide strong API guarantees to our third-party applications. But
>>> our API is inherently tied to the APR API. If somebody upgrades
>>> Subversion and that brings APR 2.0 along with it, then their
>>> application may break.
>>> Any thoughts?
>> It will take a concious decision by the user to use
>>  --with-apr-util=/path/to/apr-2-config
>> as configure will not pick up apr-2 automatically unless apr-2-config
>> masquerades as apu-config (it doesn't in a standard apr-2 install).
>> We could make it --with-apr2 to make it more obvious.
> I'm thinking of the case where a distro packager uses those
> configuration settings. Then a downstream sysadmin thinks, "they
> guarantee this is safe" and upgrades to the latest svn release. BOOM.
> Yes, we can blame the distro packager for screwing around with our
> compatibility rules, but I'd rather not give them the choice.
> Would you be okay with a --with-apr2 setting that is labeled
> "experimental" and issues a warning? ("use of this option is
> incompatible with regular Subversion releases") (or maybe the
> --with-apr2-experimental or somesuch?)

I'm happy to make it --with-apr2. I don't mind a warning but I expect
it won't get read.

I know Debian bumped the so version when they switched from apr-0.9 to
apr-1.x, i.e from libsvn_xxx-1.so.0 to libsvn_xxx-1.so.1. Perhaps we
should do something similar and make apr-2 create libsvn_xxx-1.so.2?

Received on 2011-06-21 20:42:35 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.