Re: Removing built-in support for sqlite3

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: Tue, 23 Jul 2024 14:12:27 +0200
> From: Martin Husemann <martin%duskware.de@localhost>
> 
> On Tue, Jul 23, 2024 at 07:37:30AM -0400, Greg Troxel wrote:
> > The real issue is that sqlite3 is in fact a library but upstream
> > conceives of it as a single file to be compiled into one's program,
> > while having many optional features with guidance not to have them all
> > on.  A library needs to support features that any user might want, so
> > what NetBSD has done is basically wrong, even though it follows upstream
> > norms.
> 
> Slightly off-topic here (I fully agree with dropping support for sqlite
> from base), this description makes it sound as if the proper thing (for
> NetBSD) to do is to create a private static lib for sqlite and just link
> it into any executable in the base tree that needs it - but never
> export it as a shared library (nor make it available in /usr/lib/ in the
> installed system).

This is essentially what I suggested in PR pkg/58448:

   Actually I think it would be better for base sqlite3 not to be exposed
   as a libsqlite3.so shlib, and pkgsrc should ignore the base sqlite3.

   Base sqlite3 is used only for a couple of things:

   - apropos
   - a Lua module (not sure if anything uses that, maybe it should be
     shipped separately in pkgsrc)
   - formerly Heimdal but that was bad (PR 57406) so I nixed it

   and nothing else that I know of.  And it's lagged far behind pkgsrc
   sqlite3 for a long time.  It might be better to just bake it into
   apropos and otherwise take it out of the NetBSD build.

(It doesn't require making sqlite3 _static_; it may be enough to
simply not install a .so symlink, or perhaps -- to avoid potential
soname collisions -- to install it in a non-default /usr/lib/private
path or something.  There's a good chance we'll sprout other users of
sqlite3 in base, so it may be worth keeping as a shared library.)