Re: CVS commit: src

[Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>]

> 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.