You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <eh...@gmail.com> on 2005/11/26 19:27:04 UTC
Supporting APR 0.9.4
For a long time now, we don't support APR 0.9.4. The RHEL 3 package
has patched our configure to make Subversion compile with it (because
it's the system default). Our INSTALL says we require APR 0.9.7, but
configure allows 0.9.5.
After I recently removed some code to support pre-0.9.5 APR versions,
David Summers claims the build for RHEL3 was suddenly broken. I'd
like to dispute that since he can't compile an unpatched Subversion on
RHEL3 since way before 1.0.
I'm not against David providing RHEL3 packages - on the contrary! I
think it's a good thing - but since it's his patching which makes it
work, I hold the position could easily add another patch which
reverses the 'remove-compat-code'-commits.
In other words: Can we please either have configure accept 0.9.4,
making our support for it official, or can I please remove code which
doesn't apply to supported versions, making it completely unsupported?
I'd like opinions on the above.
bye,
Erik.
Re: Supporting APR 0.9.4
Posted by Julian Foad <ju...@btopenworld.com>.
Erik Huelsmann wrote:
> For a long time now, we don't support APR 0.9.4. The RHEL 3 package
> has patched our configure to make Subversion compile with it (because
> it's the system default). Our INSTALL says we require APR 0.9.7, but
> configure allows 0.9.5.
>
> After I recently removed some code to support pre-0.9.5 APR versions,
> David Summers claims the build for RHEL3 was suddenly broken. I'd
> like to dispute that since he can't compile an unpatched Subversion on
> RHEL3 since way before 1.0.
>
> I'm not against David providing RHEL3 packages - on the contrary! I
> think it's a good thing - but since it's his patching which makes it
> work, I hold the position could easily add another patch which
> reverses the 'remove-compat-code'-commits.
Yup, that's fair.
> In other words: Can we please either have configure accept 0.9.4,
> making our support for it official, or can I please remove code which
> doesn't apply to supported versions, making it completely unsupported?
I support your plea as a sound principle that we should follow.
Whether we should currently support APR version 0.9.4 depends, for me, on how
difficult it is to do so. I think we should if it is easy, because we know
that at least one major disribution (presumably others) uses it. If it's
difficult, fair enough, we just require a later version, as we are doing.
I don't like the situation whereby INSTALL says we require 0.9.7 but configure
allows 0.9.5. If we can use 0.9.5 then that should be the minimum that we
require; it's fine for INSTALL to say that we RECOMMEND 0.9.7 (and would be
even better if it very briefly mentioned why), but it's worse than unhelpful to
say we REQUIRE it if we don't. It will just frustrate people.
The same applies, of course, to other dependencies such as Neon. I think that
topic has been raised before - about not clearly distinguishing what we require
from what we recommend. IIRC, more than one person voiced an opinion that we
can't possibly allow people to use a version that has known bugs in it that can
affect Subversion in some way - but I say that's rubbish: recommend against
using such an old version, but don't forbid it, because nearly all versions of
all software including our own has known bugs (or they sooner or later will be
known), and the well known bugs in an old version might be preferable for
certain people to some nasty newly-discovered bug in the newer version.
Obviously a hacker can work around our forbidding an old version, maybe just by
patching "configure", but he/she shouldn't have to, and it doesn't help anyone.
It would be good if "configure" were to warn if later version is specifically
recommended than the version found. Maybe the lack of that type of warning was
the reason for some reluctance to allow building against old versions.
Please let's require the oldest we can easily cope with, and recommend a later
version if there's any particular reason to do so. (I don't think it's useful
to find out what the latest version number is when we write our docs, and
recommend that specific version number just because it's the latest. It's
obvious that someone should look for the latest stable release if they need to
upgrade.)
Section E.1 of INSTALL (for installing under MS Windows) says APR 0.9.5. Is
this an accidental or an intentional difference?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Supporting APR 0.9.4
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Wed, 30 Nov 2005, Max Bowsher wrote:
>> Sounds like the consensus is then to not back out the commits and I can
>> create a patch of those revisions and apply that in the RPM build?
>>
>> Just wanted to make sure, since from now on people won't be able to
>> build Subversion "out-of-the-box" on RedHat Enterprise Linux 3 and
>> RedHat Enterprise Linux 4.
>
> Well, I presume they couldn't before, since configure denied apr 0.9.4 ?
>
This is true. I did patch the build very slightly to be able to back down
to 0.9.4 but that was basically a one-line patch to the build system, if I
recall.
- David Summers
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Supporting APR 0.9.4
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Summers wrote:
>
> On Sun, 27 Nov 2005, Garrett Rooney wrote:
>
>> On 11/26/05, Erik Huelsmann <eh...@gmail.com> wrote:
>>
>>> In other words: Can we please either have configure accept 0.9.4,
>>> making our support for it official, or can I please remove code which
>>> doesn't apply to supported versions, making it completely unsupported?
>>
>>
>> Personally, I'm in favor of just sticking to our currently stated
>> requirement of APR 0.9.5, and if packages need to depend on older
>> versions they can include the patches.
>>
>
> Sounds like the consensus is then to not back out the commits and I can
> create a patch of those revisions and apply that in the RPM build?
>
> Just wanted to make sure, since from now on people won't be able to
> build Subversion "out-of-the-box" on RedHat Enterprise Linux 3 and
> RedHat Enterprise Linux 4.
Well, I presume they couldn't before, since configure denied apr 0.9.4 ?
That said, given that these legacy OSes are going to be around for quite
a while yet, and packagers are going to link svn to pre-0.9.5 whatever
we do, I'm in favour of not a plain reversion, but a re-addition of the
compatibility code encapsulated in
"#ifdef SVN_BE_COMPATIBLE_WITH_APR_0_9_4", and appropriate configure
logic. Maybe even with a warning, saying something like:
WARNING: You are using a very old APR version. Many bugs have been fixed
in later versions. Subversion support for versions of APR this old is on
an unofficial, 'best effort' basis only!
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDjRITfFNSmcDyxYARAlAgAKCHo4gtf2rTyDR8dAJM8Sez/21+0ACcD6Wv
VkwjWfw8NNFOaMW2fmQbDtk=
=hrub
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Supporting APR 0.9.4
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Sun, 27 Nov 2005, Garrett Rooney wrote:
> On 11/26/05, Erik Huelsmann <eh...@gmail.com> wrote:
>
>> In other words: Can we please either have configure accept 0.9.4,
>> making our support for it official, or can I please remove code which
>> doesn't apply to supported versions, making it completely unsupported?
>
> Personally, I'm in favor of just sticking to our currently stated
> requirement of APR 0.9.5, and if packages need to depend on older
> versions they can include the patches.
>
Sounds like the consensus is then to not back out the commits and I can
create a patch of those revisions and apply that in the RPM build?
Just wanted to make sure, since from now on people won't be able to build
Subversion "out-of-the-box" on RedHat Enterprise Linux 3 and RedHat
Enterprise Linux 4.
Thanks,
- David
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Supporting APR 0.9.4
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 11/26/05, Erik Huelsmann <eh...@gmail.com> wrote:
> In other words: Can we please either have configure accept 0.9.4,
> making our support for it official, or can I please remove code which
> doesn't apply to supported versions, making it completely unsupported?
Personally, I'm in favor of just sticking to our currently stated
requirement of APR 0.9.5, and if packages need to depend on older
versions they can include the patches.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Supporting APR 0.9.4
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Erik Huelsmann wrote:
> For a long time now, we don't support APR 0.9.4. The RHEL 3 package
> has patched our configure to make Subversion compile with it (because
> it's the system default). Our INSTALL says we require APR 0.9.7, but
> configure allows 0.9.5.
>
> After I recently removed some code to support pre-0.9.5 APR versions,
> David Summers claims the build for RHEL3 was suddenly broken. I'd
> like to dispute that since he can't compile an unpatched Subversion on
> RHEL3 since way before 1.0.
>
> I'm not against David providing RHEL3 packages - on the contrary! I
> think it's a good thing - but since it's his patching which makes it
> work, I hold the position could easily add another patch which
> reverses the 'remove-compat-code'-commits.
>
> In other words: Can we please either have configure accept 0.9.4,
> making our support for it official, or can I please remove code which
> doesn't apply to supported versions, making it completely unsupported?
I think the previous situation arose because:
Our code worked with the released 0.9.4 API.
But, it did not work with some 0.9.4 prerelease dev snapshots, which
report themselves as 0.9.4. (And remember, for a long time, apache 2.0.x
bundled dev snapshots of apr.)
IIUC, we responded to this by just saying that we require 0.9.5.
Now, obviously, it was a LOT easier for a packager on a system with a
new-enough 0.9.4 to simply tweak the configure check, than to provide a
new apr.
Given that packages do exist, and we want them to exist, I think we
should create specific source files named apr_compat.[ch] within any
libsvn_* library which needs them (only libsvn_subr?), and use ifdefs so
that the code in them is only used with sufficiently old APR. This will
mean that we will be acting as a central repository for the compat code
various packagers will need, preventing each packager from producing
(potentially slightly different) compat patches, whilst still allowing
us to effectively minimize the impact of the compat code on the
cleanliness of the rest of our code.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDiLvTfFNSmcDyxYARAkmwAKCzNUPc9jyy9nr6Z4uCcuFSaTP7+QCggIMc
JPFF5sU4cFLsbTgH0R9yi+Y=
=dUql
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org