Re: Removing built-in support for sqlite3

[Greg Troxel <gdt%lexort.com@localhost>]

David Holland <dholland-pkgtech%netbsd.org@localhost> writes:

> (joint reply)
>
> On Mon, Jul 22, 2024 at 09:24:08AM +0200, Thomas Klausner wrote:
>  > > Is there any reason to do that vs. just setting BUILDLINK_API_DEPENDS
>  > > so the version in question isn't used?
>  > 
>  > There is currently no way to require a sqlite3 version that has a
>  > particular feature enabled.
>
> Does it not provide a config header?

It does not appear to.   The C-level API does not change; is is just
that some SQL is rejected as an error.

>  > I think heimdal was already discussed in this thread.
>
> Yes, with various proposed hacks instead of handling it with the
> infrastructure we already have for the purpose.


> On Mon, Jul 22, 2024 at 07:37:15AM -0400, Greg Troxel wrote:
>  > > Is there any reason to do that vs. just setting BUILDLINK_API_DEPENDS
>  > > so the version in question isn't used?
>  > 
>  > The problem is that many packages depend on sqlite3, and having two
>  > versions in the mix means you have a risk of linking both the base
>  > version and the pkgsrc version.
>
> That's what a global BUILDLINK_API_DEPENDS is for, isn't it?

Yes, but we need "at least this version" and "with these features", and
we are proposing basically:

  NetBSD base version is not acceptable even if the version number is
  ok, because it is feature deficient.

so that builtin.mk will not accept it.  But a bit harder, basically
"sqlite3's concept of optional featuress means that it is unsound to
ever use sqlite3 not from pkgsrc".

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.

And, as Thomas said, we need to set the default BUILDLINK_API_DEPENDS to
require a new enough version for any reasonable package use.

I don't understand what you think we should do instead.  Could you
describe it, in terms of:

  How do we reject NetBSD <=9 base sqlite3 as not having json1?

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

  How do we change to rejecting any other base sqlite3 as soon as there
  is a package that needs a feature that pkgsrc sqlite3 has and the base
  sqlite3 does not?

  Given the above, how do we ensure that no package ever links against
  any base lib which links against base sqlite3, in the (normal) case
  when base sqlite3 awas rejected?


The proposal on the table is:

  base sqlite3 is never acceptable (builtin.mk always says no, or we
  don't have one)

  builtin.mk for any package where base uses base sqlite3 is coded to
  reject it

and that seems necessary and sufficient.

What do you want us to do instead?