Bug#729426: Tighten versioned dependency on SQLite3
Package: subversion Hi, It seems the subversion dependency on libsqlite3-0 (via libsvn1) needs tighter versioning. Currently a mismatch can result in errors like these: svn: E200029: Couldn't perform atomic initialization svn: E200030: SQLite compiled for 3.8.0.2, but running with 3.7.13 Regards, — Wouter signature.asc Description: This is a digitally signed message part
Bug#729426: Tighten versioned dependency on SQLite3
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
Bug#729426: Tighten versioned dependency on SQLite3
Peter Samuelson schreef op di 12-11-2013 om 15:27 [-0600]: [...] 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. Oh well, that looks harder than I thought. Thanks for the detailed analysis. Actually, I suspected it would only be a minor change to a control file, but as always, reality is more complex than it seems. :) Anyway, it's not that important; the error message was pretty helpful after all, so the issue was quickly resolved. — Wouter signature.asc Description: This is a digitally signed message part
Bug#729426: Tighten versioned dependency on SQLite3
On Tue, Nov 12, 2013 at 03:27:07PM -0600, Peter Samuelson wrote: [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. Upstream 1.8.x has changed to allow specifying the minimum supported SQLite version as an argument to configure, so we could set that to max(stable's SQLite, minimum version SVN requires) and update the (Build-)Depends appropriately. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
