Re: Removing built-in support for sqlite3

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

> Date: Tue, 23 Jul 2024 09:52:10 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost> writes:
> 
> > (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.)
> 
> Agreed on all that, except if it's a shlib it can't have the normal name
> and if shlib or static, the normal symbols, because you can still end up
> with two colliding copies.
> 
> Essentially any library in base needs to be such that linking it and
> linking pkgsrc sqlite is going to be ok.

Yes, that's why I eliminated sqlite3 from all libraries in base one
might reasonably link against.

We should go through and put a large number of remaining libraries,
which are technically exposed as /usr/lib/lib*.so, and make them more
private, as only /usr/lib/private/lib*.so.N.

Obvious candidates include the Heimdal hdb and kadm libraries, and all
the ISC libraries (except for the part where we should really, finally
just stop shipping BIND and dhcpd in base and end the futile
maintenance nightmare).

> What's really causing trouble is two things:
> 
>   sqlite3's concep of optional features, and NetBSD base not having them
>   all on
> 
>   any lib in base which gets linked into any other lib in base, doesn't
>   have a good story about how using a newer version of that lib from
>   pkgsrc in a program won't cause problems.

We should generally try to limit what nonessential functionality is
exposed through shared libraries in base.

> For the second point, we sort of need linker support for
> 
>  A links to
> 
>    B (new sqlite3 from pkgsrc)
> 
>    C (libfoo in netbsd base), which links to
> 
>      D (old sqlite3 from base
> 
> and have C's use of sqlite3_bar symbols resolve to D while A's use
> resolves to B.  And similarly for other graphs.   I may be off, but I
> have the impression this does not work, at least reliably.

It works if library C renames all the symbols, which is what I
suggested for Heimdal in the future:

https://github.com/heimdal/heimdal/issues/1142