2014/1/4 Richard Hipp <[email protected]>:
> 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
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
