On Tue, Jun 21, 2011 at 14:41, Philip Martin <philip.martin_at_wandisco.com> wrote:
> 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.
Heh. --with-apr2-no-I-really-mean-it :-P
> 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?
That works for ELF. How about Windows?
Another approach to take for now, and work this out over time, is to
allow --with-apr2 to be specified *only* when --enable-maintainer-mode
is enabled. I doubt packagers will be turning that on :-)
Cheers,
-g
Received on 2011-06-21 20:48:37 CEST