On Sat, Oct 29, 2011 at 07:28:07AM -0500, Jonathan Nieder wrote:
> Daniel Shahaf wrote:
> > On Saturday, October 29, 2011 6:45 AM, "Jonathan Nieder" <jrnieder_at_gmail.com> wrote:
>
> >> The actual ABI compatibility of sqlite3 doesn't depend on the patchlevel
> >> (the x in 3.7.x),
> >
> > [citation needed]
> >
> > (I already searched sqlite.org for "ABI" and "binary compatibility" and so on; zero matches)
>
> Sloppy me. In fact, if I had only looked at the changelog, I would
> have found many cases of introduction of new ABI in 3.7.x versions.
>
> In Debian, that is already handled by checking at build time which
> version introduced each function that is used and setting appropriate
> dependencies through the package manager, fortunately, so as a
> distro-specific patch it was not doing much harm. A more useful and
> less misleading patch would involve doing something like the
> following. Sorry for the nonsense, and thanks very much for catching
> it quickly.
OK, so in this case I would prefer if distros patched Subversion accordingly.
The Subversion project already recommends appropriate sqlite versions.
If distros like Debian want to play by different rules then let's have
them take the burden.
(I seem to recall that Debian is using rather relaxed rules for shared
library versioning, since they cannot afford to recompile every package
all the time.)
>
> Index: subversion/libsvn_subr/sqlite.c
> ===================================================================
> --- subversion/libsvn_subr/sqlite.c (revision 1194866)
> +++ subversion/libsvn_subr/sqlite.c (working copy)
> @@ -606,6 +606,7 @@
> static svn_error_t *
> init_sqlite(void *baton, apr_pool_t *pool)
> {
> +#if !defined(PACKAGE_MANAGER_CHECKED_THE_VERSION_NUMBER_ALREADY)
> if (sqlite3_libversion_number() < SQLITE_VERSION_NUMBER)
> {
> return svn_error_createf(
> @@ -613,6 +614,7 @@
> _("SQLite compiled for %s, but running with %s"),
> SQLITE_VERSION, sqlite3_libversion());
> }
> +#endif
>
> #if APR_HAS_THREADS
>
Received on 2011-10-29 14:39:01 CEST