On Tue, Nov 10, 2020 at 04:29:21PM +0000, Taylor R Campbell wrote: > > 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.
libevent is also problematic. Maybe there's just too many third-party libraries that are exposed that sholdn't be.