You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2011/06/21 19:44:11 UTC
Re: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4
configure.ac
On Tue, Jun 21, 2011 at 11:16, <ph...@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?
Cheers,
-g
Re: svn commit: r1138040 - in /subversion/trunk:
build/ac-macros/apache.m4 configure.ac
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jun 21, 2011 at 08:44:10PM +0200, Bert Huijben wrote:
> How did we handle the transition from apr 0.9 to 1.X?
Ben put a huge ASCII box into INSTALL that warned about
compatibility issues. Not sure if more than that happened.
Re: svn commit: r1138040 - in /subversion/trunk:
build/ac-macros/apache.m4 configure.ac
Posted by Peter Samuelson <pe...@p12n.org>.
[Bert Huijben]
> How did we handle the transition from apr 0.9 to 1.X?
I complained that we were breaking ABI compatibility, and it turned
into a miniature flame war, and in the end, nothing happened. Then,
later, when we decided to ship apr 1.x in the -deps tarball, someone
added a big warning to the release notes about the ABI ramifications.
In Debian, as someone mentioned already, I've been maintaining a patch
to handle this more or less "correctly":
svn://svn.debian.org/pkg-subversion/src/1.7.x/debian/patches/apr-abi
I changed the SONAMEs in the libraries, _and_ changed the name of the
package that provides them. Thus your old apps, linked to the old
libsvn and the old libapr, and your new apps, linked to the new libsvn
and the new libapr, could coexist on your system and everything would
work perfectly. Eventually, if you recompiled or upgraded all your old
apps, you could uninstall the old libsvn, apr, and apr-util packages.
Tracking this was no different from tracking any other "when can I
uninstall this old library" scenario.
I (once again) suggest something like that be done officially for apr2,
though I note I was also sloppy about hardcoding the 0 -> 1 in part of
that patch; the official solution should be a bit more thorough.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
RE: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4 configure.ac
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: dinsdag 21 juni 2011 20:31
> To: Philip Martin
> Cc: dev@subversion.apache.org
> Subject: Re: svn commit: r1138040 - in /subversion/trunk: build/ac-
> macros/apache.m4 configure.ac
>
> On Tue, Jun 21, 2011 at 14:15, Philip Martin <ph...@wandisco.com>
> wrote:
> > Greg Stein <gs...@gmail.com> writes:
> > 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?)
How did we handle the transition from apr 0.9 to 1.X?
This was about the same situation, except that apr 2.0 is still completely
experimental now.
(But that might change before Subversion 1.8)
Bert
Re: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4 configure.ac
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2011-06-22 00:19:21 Peter Samuelson napisał(a):
> Well, I was mainly thinking of platforms like Gentoo Linux that seem
> like they're big on early adoption and not so big on ABI stability and
> support lifetime. I don't know if my perception is accurate, but I get
> the feeling they are, in general, happy to accept "recompile the world"
> as a substitute for keeping old libraries around for a gradual upgrade
> transition.
Users of stable versions of Portage (main package manager) can use revdep-rebuild script,
which detects packages containing executables/libraries linked against no longer existent
libraries.
Users of experimental versions of Portage can use new "preserve-libs" functionality, which
preserves libraries from older versions of packages until reverse dependencies are rebuilt
with new libraries.
In some situations, it is possible to have multiple versions of given package installed
simultaneously. This possibility must be declared in ebuilds of given package and there
should be no file collisions. E.g. it is possible to have Python 2.4.*, 2.5.*, 2.6.*, 2.7.*,
3.0.*, 3.1.*, 3.2.* and 3.3.* installed simultaneously (but not both e.g. 3.1.3 and 3.1.4).
It is possible to have APR 1.* and 2.* installed simultaneously. (The ebuild for APR 2.0_pre*
is absent in main repository and is present in my private repository.)
--
Arfrever Frehtes Taifersar Arahesis
Re: svn commit: r1138040 - in /subversion/trunk:
build/ac-macros/apache.m4 configure.ac
Posted by Peter Samuelson <pe...@p12n.org>.
> On Tue, Jun 21, 2011 at 17:04, Peter Samuelson <pe...@p12n.org> wrote:
> > Good question. libtool has machinery to track this stuff. My
> > aforementioned patch uses libtool's "-version-info 0" and
> > "-version-info 1". How does libtool handle -version-info on Windows?
[Greg Stein]
> We don't use libtool on Windows. Simple as that :-P ... IOW, we'd
> have to figure out how to fix the problem within our current Windows
> system.
Right ... I mainly just meant, if libtool supports the Win32 platform,
we should look at how they handle DLL versioning, and do something
similar.
> > *Nod*. So, more or less table the issue until apr2 gets to a point
> > where it's being shipped to end users and apr1 is not.
> > when that's expected to happen, but presumably it's not a concern for
> > 1.7.x.
>
> APR 1.x is going to be around for a long, long time. I don't know
> that "apr1 is not" will ever happen because I think svn is going to
> continue to rely on it, so it'll need to stick around.
Well, I was mainly thinking of platforms like Gentoo Linux that seem
like they're big on early adoption and not so big on ABI stability and
support lifetime. I don't know if my perception is accurate, but I get
the feeling they are, in general, happy to accept "recompile the world"
as a substitute for keeping old libraries around for a gradual upgrade
transition.
But it's possible that even the early adopters will continue to provide
apr1 for a good long time yet.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4
configure.ac
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jun 21, 2011 at 17:04, Peter Samuelson <pe...@p12n.org> wrote:
>
> [Greg Stein]
>> > 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?
>
> Good question. libtool has machinery to track this stuff. My
> aforementioned patch uses libtool's "-version-info 0" and
> "-version-info 1". How does libtool handle -version-info on Windows?
We don't use libtool on Windows. Simple as that :-P ... IOW, we'd have
to figure out how to fix the problem within our current Windows
system.
>> 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 :-)
>
> *Nod*. So, more or less table the issue until apr2 gets to a point
> where it's being shipped to end users and apr1 is not. I have no idea
> when that's expected to happen, but presumably it's not a concern for
> 1.7.x.
Right. We can futz with it over the 1.8 development lifecycle. But by
keeping it under the maintainer mode, we can also be sure that
somebody won't Do Something Wrong with it.
APR 1.x is going to be around for a long, long time. I don't know that
"apr1 is not" will ever happen because I think svn is going to
continue to rely on it, so it'll need to stick around.
Cheers,
-g
Re: svn commit: r1138040 - in /subversion/trunk:
build/ac-macros/apache.m4 configure.ac
Posted by Peter Samuelson <pe...@p12n.org>.
[Greg Stein]
> > 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?
Good question. libtool has machinery to track this stuff. My
aforementioned patch uses libtool's "-version-info 0" and
"-version-info 1". How does libtool handle -version-info on 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 :-)
*Nod*. So, more or less table the issue until apr2 gets to a point
where it's being shipped to end users and apr1 is not. I have no idea
when that's expected to happen, but presumably it's not a concern for
1.7.x.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4
configure.ac
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jun 21, 2011 at 14:41, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> On Tue, Jun 21, 2011 at 14:15, Philip Martin <ph...@wandisco.com> wrote:
>>> Greg Stein <gs...@gmail.com> writes:
>>>
>>>> On Tue, Jun 21, 2011 at 11:16, <ph...@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
Re: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4 configure.ac
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> On Tue, Jun 21, 2011 at 14:15, Philip Martin <ph...@wandisco.com> wrote:
>> Greg Stein <gs...@gmail.com> writes:
>>
>>> On Tue, Jun 21, 2011 at 11:16, <ph...@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
Re: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4
configure.ac
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jun 21, 2011 at 14:15, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> On Tue, Jun 21, 2011 at 11:16, <ph...@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?)
Cheers,
-g
Re: svn commit: r1138040 - in /subversion/trunk: build/ac-macros/apache.m4 configure.ac
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> On Tue, Jun 21, 2011 at 11:16, <ph...@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.
--
Philip