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?
--
Philip
Received on 2011-06-21 20:42:35 CEST