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

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

On Wed, 19 Aug 2026, Greg Troxel wrote:
> 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.)

Indeed - I was hoping to trick someone else into writing it.

> > 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 checked on the the release branches and shlib_version has altered as 
follows:

netbsd-8: 6.1 -> 6.2 (not after release of 8.0)
netbsd-9: 6.2 -> 9.0 (NetBSD 9.3 -> 9.4)
netbsd-10: 7.0 -> 9.0 (not after release of 10.0)
netbsd-11: 9.0 -> 11.1 (not after release of 11.0)

So we did alter it once after a formal release.

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

Yes. Of course setting UNBOUND_USER=_unbound and 
UNBOUND_GROUP=_unbound also avoids the extra user.

--
Stephen