Re: Removing built-in support for sqlite3

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Tue, Jul 23, 2024 at 05:53:38AM +0000, David Holland wrote:
> (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?

I don't understand how this addresses the point.  If today I wanted
sqlite3 with FOO_FEATURE enabled, how do I do that?

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

The hack is to switch to pkgsrc heimdal?
What is 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?

I read this as: If only one of the packages in pkgsrc wants a newer
sqlite3 and the other ones are happy with the old one, we need to bump
the global BUILDLINK_API_DEPENDS. Or what do you mean?
 Thomas