Greg Stein <gst...@gmail.com> writes: > On Tue, Jun 21, 2011 at 14:15, Philip Martin <philip.mar...@wandisco.com> > wrote: >> Greg Stein <gst...@gmail.com> writes: >> >>> On Tue, Jun 21, 2011 at 11:16, <phi...@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
