Re: Why no builtin.mk for net/unbound?

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

Martin Husemann <martin%duskware.de@localhost> writes:

> On Wed, Aug 19, 2026 at 09:27:54AM +0100, Stephen Borrill wrote:
>> On Wed, 19 Aug 2026, Martin Husemann wrote:
>> > Is it a good idea to reuse that lib from pkgsrc?
>> 
>> I think so. The current status is that if you want to use lua-unbound for
>> DNS client queries, it brings in a whole duplicate DNS server (which also
>> creates its own user)

Generally, if there's something from the base OS (whether it's NetBSD or
something else) that's usable, we have a builtin.mk.  The hard question
is setting the default API_DEPENDS and other parts of "is this good
enough", but that just turns into "programs that are pickier have to set
a variable" and "programs that are less picky can set a variable to use
builtin in more environments".

(I think it's also true that writing builtin.mk is harder than people
think and we have a lot of not-right builtin.mk files now.)

> The question is if the ABI of the library is relatively stable. If not,
> we will never be able to pull up newer unbound versions to any release
> branches. Looking at /usr/lib/libunbound.so.* on a random system here
> I see 7.0 to 11.1 versions from mid 2023 untill now. This already
> make me think we should move it to /usr/lib/private/....

If the ABI is not stable, then you can't pull up newer versions if it's
part of the base system, regardless of whether pkgsrc uses it or not.

> I don't know why/how lua-unbound uses libunbound (instead of libc).
>
> Maybe a better solution would be to split the unbound pkg or create
> a lib-only variant of it, so lua-unbound could depend on lib-unbound
> only and not get the dns cache+extra user.

That does sound good, regardless of builtin.mk.