Re: Removing built-in support for sqlite3

[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.

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.


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.