> Module Name: src > Committed By: nia > Date: Sun Nov 8 21:56:48 UTC 2020 > > Modified Files: > src/external/bsd/kyua-cli: Makefile.inc > src/external/ibm-public/postfix: Makefile.inc > src/external/public-domain/sqlite: Makefile.inc > src/external/public-domain/sqlite/bin: Makefile > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > src/usr.sbin/makemandb: Makefile > > Log Message: > sqlite: do not build without multithreading support > > at least a few pkgsrc packages avoid base sqlite because it fails > this check, and it's probably a surprising performance penalty for > unsuspecting users
Why do we even expose NetBSD's libsqlite3.so to pkgsrc? Why not just have pkgsrc always use pkgsrc sqlite3, and change base to go back to the smaller non-threaded sqlite3 with only the options the things in base actually need? Also: What is the performance penalty? The sqlite3 documentation (https://www.sqlite.org/faq.html#q6) suggests that _enabling_ SQLITE_THREADSAFE has a performance penalty, not the other way around. It seems to me we've had a lot of problems over the years trying to use base sqlite3 for everything in pkgsrc. It's not clear to me that any of the recent changes are helpful for the three things in base that need sqlite3, and it's also not clear that they will help with running newer pkgsrc on older NetBSD.