> Date: Thu, 12 Nov 2020 11:21:43 -0800 > From: Jason Thorpe <thor...@me.com> > > > On Nov 12, 2020, at 9:40 AM, nia <n...@netbsd.org> 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.