2014/1/4 Richard Hipp <d...@sqlite.org>: > OK, so I propose the following fix: > > (1) Move [bd1151126a] into a branch. > (2) Remove the --disable-internal-sqlite option on trunk. Require the use > of the built-in SQLite only, since SQLite needs to be built with > non-standard compile-time options to fully meet the needs of Fossil. > (3) Cherry-pick check-ins after [bd1151126a] onto the trunk. > (4) When distributions complain, we simply explain that we tried using an > external SQLite but it introduced too many complications and bugs and that > we now require statically linking SQLite for reasons of security and > reliability. > > Comments?
How about this counter-proposal? Explanation follows: (1) Update fossil to require SQLite 3.7.17 as a minimum in stead of the current SQLite 3.7.0. See: <http://fossil-scm.org/index.html/timeline?r=sqlite-min-to-3.7.17> (2) Eliminate the strglob() function from fossil, use the sqlite3_strglob() function (available since SQLite 3.7.17) instead. I tested this change: all unit-tests work fine. (3) After SQLite 3.8.3 is released, release fossil 1.28 with the EXACT SQLite 3.8.3 amalgamation included. (4) Immediately after the fossil 1.28 release, add a runtime-check for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add "WITHOUT ROWID" to whatever SQL statement it is useful. Unconditionally! (5) Future official fossil release should contain an official released SQLite amagalmation as well, but less frequent: There is no need to make a new Fossil release after each SQLite release. I think this counter-proposal will gain a lot more sympathy to the various package-maintainers. And it has more advantages. Explanation: at (1): Supporting every SQLite 3.7.x release is madness, SQLite 3.7.17 is more than 7 months old now, that should be enough time for whatever distribution to upgrade to it. at (2): Code duplication is always bad. Requiring SQLite 3.7.17 as a minimum makes sure the sqlite3_strglob() function is available. That's an immediate gain. at (3): Advantage: official SQLite releases are better tested than intermediate ones. Fossil 1.27 contains a SQLite 2.8.1 beta with a bug which is crucial on Cygwin. See: <http://osdir.com/ml/sqlite-users/2013-12/msg00193.html> This bug is discovered during release testing of SQLite 2.8.2 (when I became Cygwin's SQLite maintainer), if fossil would have been compiled with --disable-internal-sqlite the bug would have been fixed now. at (4): If SQLite 2.8.3 is released around February, then a reasonable Fossil 1.29 release could be done mid 1014. That's more than enough time for whatever distribution to upgrade to SQLite 2.8.2. And it means that starting one month from now Fossil developers don't need to worry about WITHOUT ROWID support: just use it whenever appropriate. at (5): This means that part of the pre-release testing of every Fossil release should be a test using --disable-internal-sqlite, in order to verify that Fossil really works well with the lowest SQlite version it is documented to work with. I volunteer to do this pre-release test. On Cygwin, keeping --disable-internal-sqlite would have the advantage that fossil can take advantage of the improved "win32-longpath" VFS (and the new "unix-cygwin" VFS) without the Fossil maintainer (Jari Aalto) having to replace the SQLite amagalmation with every new Fossil release. As soon as the Cygwin enhancements are adopted by SQLite (in whatever modified form), --disable-internal-sqlite doesn't give any advantage on Cygwin any more. But as long as that doesn't happen, I hope that --disable-internal-sqlite will be kept as-is. Regards, Jan Nijtmans _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users