Re: CVS commit: src

[nia <nia%NetBSD.org@localhost>]

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.