I think we should revisit this topic again.
Stefan Sperling apparently ran into a repository corruption Subversion 1.8.4 on
RedHat 5 using the system APR (1.2.7). I'm not sure of the details but I'm
sure he can fill them in.
If old versions of APR are causing repository corruption issues then we're
failing our users by not rejecting these versions of APR. We can't expect our
users to know about these things unless we tell them. Right now we communicate
version requirements in 4 places.
1) INSTALL file, which says that you need 0.9.7 or 1.x.x of APR (doesn't really
mention APR-util but the implication is the same version requirements).
2) configure, which allows APR 0.9.7 - 0.9.19 and 1.x and 2.x and the same
versions of APR-Util (though no 2.x since the two were merged). Note that APR
0.9.20 (there is no such APR-util version) is excluded for no apparent reason.
I guess nobody updated the regular expression when it was released in 2011.
3) The Windows build requires APR and APR-Util be newer than 0.9.0. So it's
not enforcing the 0.9.7 requirement that's documented in configure.ac as being
needed for FSFS repository integrity.
4) get-deps.sh, which downloads APR 1.4.6 and APR-Util 1.5.1.
The last time this came up it was because Serf requires APR 1.3.x due to some
error handling. One of our build bots actually has a patched version of Serf
in order to allow it to build with older versions of APR.
The reason we didn't change was that we were concerned presenting difficulties
to users who were on OSes with old versions of APR. If old versions of APR can
cause repository corruption then we're simply trading an inconvenience
(upgrading OS, building a newer APR, etc) for a real problem.
Which leaves the question open as to what version to require. I believe we
should require at least 1.3.x (we know Serf needs it). But would be satisfied
if we can narrow it down to the specific APR versions that cause these problems.
In the case that Stefan Sperling ran into these were binary packages. People
producing binary packages generally find out what doesn't work from our
documentation and our build system. In some cases our binary packagers have a
lot more knowledge than the average user but let's not pretend that all of them
have that knowledge.
It's our burden to set useful dependency requirements. There's plenty of room
for recommendation versus requirements in the 4 places above (build system is
requirement, INSTALL and get-deps.sh are recommendation). Let's update our APR
requirements.
Received on 2014-02-05 19:37:21 CET