On Sat, Apr 21, 2012 at 17:59, Daniel Shahaf <danielsh_at_elego.de> wrote:
> 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.
Yeah, but 3.7.11 is the "current" version, and we don't know when the
next version will be released. But if we know 1.7.5 is going out
"now", then we can add a check. And who knows about package skew for
the next year or so...
Maybe I don't understand the bug entirely, but it seems "don't use
this at all" is where we're at. That is very different from some bug
in apr 1.3.2. If this sqlite issue makes svn a total non-starter, then
I think we ought to warn about it.
And best way is with a runtime check. We could also have a compile
time check, which helps packagers.
Blair? How badly did this really impact svn? It sounds like it was
only for an upgraded working copy? Upgraded from 1.6? I wonder how an
upgraded wc would differ from a normal checkout... ??
>> > 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).
Maybe. I think it really depends upon the problem. For example, we
couldn't even *start* svn with 3.7.7. We had to wait for 3.7.7.1 to be
released. No about of "check disable" would allow us to run against
3.7.7.
>> 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
Right.
> 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?
Furthermore, these checks slowly disappear over time. We used to have
a lot of version-dependent code in sqlite.c. But then we said "minimum
version is $whatever" and deleted a bunch of those checks.
If we put in a check to avoid 3.7.11, then it will get deleted once we
set a 3.8 minimum (for example).
These checks are also pretty darned isolated. They aren't really
"littered" around the codebase.
>...
> If we could have the same check either in code or in a documentation
> somewhere, I'd vote for the former.
I strongly concur.
Cheers,
-g
Received on 2012-04-22 00:08:43 CEST