[Bug 263499] [NEW PORT] dns/bind918-noxml

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 31 May 2022 10:20:01 UTC

--- Comment #7 from Leo Vandewoestijne <freebsd@dns.company> ---
Created attachment 234348
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234348&action=edit
bind918 with more options

Then you basically will have duplicate ports,
and so will create double maintenance tasks.

But besides
If I'm authoritative, and for example I don't want DoH
and therefor wish to be
which is now not optional AND comes with

Further there is
which is neither optional, but in my case I could

Then I don't rely on Bind to deal against abuse or metrics.
My DNS daemons only needs to do DNS (...).
And so I can
and actually -in my own usecase- even

And usually compression comes with extra overhead, so in case I serve tiny
zones for an "Alexa500" domain, then I prefer it

To prevent surprises when defaults changes, I think it's wise to explicitly

Long story short;
your new port is neither going to solve this all, only the XML portion.
The real port should empower users to use the port to install software to their
IMHO that's what it is meant for.
But currently I use my own port instead.
Which again is a duplication of task.

If the portmaintainer wishes to keep things simple, why not have a "base port"
to be used by metaports "bind-tools", "bind918" and a "bind918min"

But I could imagine even that can be considered overcomplicated.
I think the easiest is just to simply have the options in the main port.
Therefor I created attached patch (tested successful on 13.0 AMD).
I think it's the best (or least bad) solution.
So @mat, please consider this, or maybe suggest an alternative solution.

If OP considers my contribution kind of a treadjack and wish to focus on the
suggested dns/bind918-noxml then please reclaim attention on that.

You are receiving this mail because:
You are on the CC list for the bug.