Re: CVS commit: src

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

> Date: Thu, 12 Nov 2020 11:21:43 -0800
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> > On Nov 12, 2020, at 9:40 AM, nia <nia%NetBSD.org@localhost> wrote:
> > 
> > For the record I'm just trying to fix things so that running
> > third-party software on NetBSD sucks less. If fewer third-party
> > libraries were exposed by the base system this wouldn't be
> > necessary.
> 
> Why do we even have sqlite in the base system in the first place?

apropos(1); a handful of other things also use it (heimdal, postfix).

I suggested that we leave the bells & whistles out of base sqlite3,
maybe even stop installing the .so symlink, and teach pkgsrc to just
use pkgsrc sqlite3 (with all bells & whistles included) rather than
base sqlite3 -- after all, sqlite3 is meant to be embedded and has
lots of optional bells & whistles that apropos(1) has no need of, so
it is silly to impose those costs on apropos(1) or make sqlite3 part
of the NetBSD API.

But there's a snag with heimdal.

Heimdal exposes the sqlite3 library to clients via libgssapi.so which
links against libkrb5.so which brings in libsqlite3.so.  So we get nice
situations like this:

% ldd /pkg/2020Q2/bin/svn | grep sqlite   
        -lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0
        -lsqlite3.1 => /usr/lib/libsqlite3.so.1

This is also why the change to base sqlite3 affected, e.g., su(1).

I have no idea what heimdal does with sqlite3, but it puts us in a
pretty pickle: we can't reliably use pkgsrc sqlite3 on existing NetBSD
installs for packages that use gssapi, and we can't rely on sqlite3 in
existing NetBSD installs for packages that need newer/threaded/jsonned
sqlite3 as we often encounter.