Re: Removing built-in support for sqlite3

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

> Date: Sun, 4 Aug 2024 22:58:12 +0000
> From: David Holland <dholland-pkgtech%netbsd.org@localhost>
> 
> On Tue, Jul 23, 2024 at 07:37:30AM -0400, Greg Troxel wrote:
>  >   How do we reject NetBSD <=9 base sqlite3 as not having json1?
> 
> Blacklist it by OS version in sqlite3/builtin.mk, since there doesn't
> seem to be any way to detect its build config.
> 
> Maybe in the future we can figure out how to make the logic used for
> checking package build options also work with builtin packages. And
> maybe then hack the base sqlite to interoperate; doesn't need to be a
> particular portable solution.

Why put all that effort into this when we could just delete the
unnecessary and harmful code like wiz@ suggested?

>  >   Do we believe that NetBSD-current sqlite3 is sufficient for every
>  >   package in pkgsrc that uses sqlite3?
> 
> No idea.

Answer: absolutely not.

Base sqlite3 is deliberately limited in various ways for specific
reasons (like disabling thread safety), so it is generally harmful to
expose to pkgsrc.

It's hard to avoid exposing it in netbsd-8 and netbsd-9 because of
Heimdal's use of sqlite3 (which was half-baked and unusable and never
should have been turned on in the first place and is now turned off in
10 and current) which leaks into libgssapi which various pkgsrc
applications use -- that is, unless builtin Heimdal is avoided too.

The only reasonable way to build pkgsrc sqlite3 as a library for all
other packages that use it is with all the build options enabled that
_any_ downstream packages might use, but base sqlite3 probably won't
ever be built like that and certainly it moves slower so it'll always
be problematic.