-----BEGIN PGP SIGNED MESSAGE-----
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Nov 26 20:48:09 2005