On Sat, Apr 21, 2012 at 11:51 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sat, Apr 21, 2012 at 07:49:37AM -0500, Hyrum K Wright wrote:
>> On Fri, Apr 20, 2012 at 10:15 PM, Greg Stein <gstein_at_gmail.com> wrote:
>> > Seems we can/should have a runtime version check? Avoid running with 3.7.11?
>> I dunno. Arguably, there are bugs in many versions of our dependency
>> libraries which affect us, yet we don't special case them out. By the
>> time anybody upgrades their Subversion to obtain the version check,
>> they'll probably have upgraded their SQLite as well, so I don't see it
>> as a very big issue.
> I think we should block or at least warn about dependencies with known
> bugs. There should be a way to force use of the dependency if necessary
> (like the --disable-neon-version-check option).
It's a slippery slope. We've got a number of dependencies, and there
is no possible way to test or even keep up with the various
permutations of them that may be installed. We do our best, but I
just don't think we ought to litter our code with version checks and
warnings when we get user-reported issues like this. It's a
> Whether or not a given system has version A of dependency X is often
> not a direct decision made by the system's users. For example, a buggy
> dependency might slip into a long-term supported release of systems
> people use (Debian stale, Redhat, and the like). It's better to make
> packagers aware of known problems at build time, rather than waiting
> for users of the packages to find problems and file duplicate reports.
I would go a step further and say it's better to let packagers know
though the documentation, rather than via technical means. Put
somewhere on the website the list of deps versions which break
Subversion. We may not expect typical users to refer to this, but I
think we can hold packagers to the higher standard.
uberSVN: Apache Subversion Made Easy
Received on 2012-04-21 23:00:38 CEST