reassign 729426 libsvn1
forcemerge 721878 729426
thanks
[Wouter Bolsterlee]
> svn: E200029: Couldn't perform atomic initialization
> svn: E200030: SQLite compiled for 3.8.0.2, but running with
> 3.7.13
Thanks. The problem is that there's 3 different opinions on this
dependency, and none of them match:
(1) sqlite3 shlibs and symbols files;
(2) The configure + build process detects SQLite features and optimizes
the build to use whatever features it knows it can rely on;
(3) To be on the safe side, as it were, libsvn1 does a runtime check to
make sure the SQLite version is at least as recent as the one it was
built with. (That's the error you see above.)
So the problem is that what we need is (2), but what we actually get is
(1) which is unsafe because it is not strict enough, and (3) which is
too strict. At some point I patched (3) so it only cares about
'major.minor' rather than 'major.minor.patch', but as you can see, that
is still too strict.
It's been suggested we use runtime detection of SQLite features in
libsvn1, but that's not really convenient: if I remember correctly, the
build process involves compiling SQL queries which may use newer SQLite
features. I'll try to look into it anyway - I expect upstream would be
interested.
What we will probably do instead is patch out (3), audit the (2) cases,
and hard-code a minimum SQLite version, to be adjusted every major new
Subversion release that may make use of additional SQLite features.
Peter
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
