Hyrum K Wright wrote on Sat, Apr 21, 2012 at 16:00:02 -0500:
> 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
What permutations? We don't care what the bdb or neon version is when
checking the sqlite version, and we don't care if there is more than one
sqlite on the system either.
> 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
> maintenance nightmare.
How so? Did we have more than one or two of those bugs per year?
>
> > 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.
>
If we could have the same check either in code or in a documentation
somewhere, I'd vote for the former.
> -Hyrum
>
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
Received on 2012-04-21 23:59:51 CEST