On 2022/03/16 23:53, Lucas wrote:
> - added an optional but recommend dependency on a new port which
> provides Lua bindings for libunbound, net/luaunbound, developed by
> one of the Prosody devs
luaunbound needs NO_TEST, otherwise it's OK with me to import
> This last new dep is attached as a tarball in this email (lemme know if
> I should start a new thread instead). I created the tarball relative to
> `/usr/ports`, as I didn't find much information on where should I do it,
> and I ported it because it's really small and simple, seemingly a good
> candidate to learn how to create a new port.
either /usr/ports or /usr/ports/$category. if you're sending several
small ports in one go which are all related (e.g. a couple of new
deps for an port you're updating, or a new port which needs a couple
of other small ports) then it's easier for the reviewer to put them
in a single tar. (if it's more than a couple then it's often better
to send them in manageable chunks with a quick overview of how things
will fit together at the start).
> It's currently running on my -current instance without any issue, and
> I'd love to see it in 7.1, as I think it would ease maintainance:
> 0.11.x will still be supported but not actively developed, and in that
> case I don't know if I would need split ports for the different versions
> or whatever.
seems sensible if you're happy that 0.12.0 is solid enough.
(with some software it makes sense to wait for a point release or two
after a big update, with others it doesn't, I don't know prosody well
enough to know which applies here :)
> Of course, as soon as I sent this email I remembered I forgot to check
> if the new plugin manager with LuaRocks works. It does, but not out of
> the box: it's invoked as `luarocks`, while it should be `luarocks-5.3`
> in this case. I could patch it to literal `luarocks-5.3`, but I think
> it would be more correct to patch it to something that doesn't force me
> to keep both in sync, something like `luarocks-${MODLUA_VERSION}` and
> then replace. Is that the correct approach? Patching like that and then
> adding a `post-patch:` target using ${SUBST_CMD}?
exactly
