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
Section E.1 of INSTALL (for installing under MS Windows) says APR 0.9.5. Is
this an accidental or an intentional difference?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Nov 26 21:21:56 2005