Created attachment 233425 [details] [PATCH] dns/bind918-noxml: new port Hi, here's new port bind918 without XML support. Could you please review it. Thanks. -- Sergey A. Osokin
Can you elaborate on why this is needed? I think it would be a better idea to either provide it as an option (which current maintainer didn't approve) or as a flavoured port but most seem to bundle libxml2? Alpine Linux --> Bundles (non optional) Arch Linux --> Bundles (non optional) Debian --> Bundles (non optional) Gentoo --> Bundles (non optional?) Fedora --> Bundles (non optional) OpenSUSE --> Bundles (non optional)
(In reply to Daniel Engberg from comment #1) Some of us do not like extra dependencies. From upstream (ISC) point of view, libxml2 support is optional non-default feature used to collect statistics useful for some heavy loaded sites, but not for all users. libxml2 has its own backlog of security vulnerabilities and even memory leaks. Upgrades of libxml2 will not require upgrade of DNS server if it is build without optional XML2 feature.
(In reply to Daniel Engberg from comment #1) Please take a look on NetBSD, http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/net/bind916/options.mk?rev=1.4&content-type=text/x-cvsweb-markup ### ### The statistics server in bind99 and later needs libxml2 ### .if !empty(PKG_OPTIONS:Mbind-xml-statistics-server) .include "../../textproc/libxml2/buildlink3.mk" CONFIGURE_ARGS+= --with-libxml2 LDFLAGS+= -lxml2 .else CONFIGURE_ARGS+= --without-libxml2 .endif
Guys, this is ridiculous. Just add the option to BIND, default to on, and be done with it. Most people won't even notice, those who need it would turn it off. The "I don't like it" reason of closing the original bug #253480 is bogus.
(In reply to Alexey Dokuchaev from comment #4) > Guys, this is ridiculous. Just add the option > ... > The "I don't like it" reason of closing the original bug #253480 is bogus. > That was just one "argument". The other being amount of security advisories of Bind itself: the more security advisories, the worse the software - right? Once ago, in 9.16 or before, I needed TUNING_LARGE, while serving large zones (some over 20GB). It made the difference between being able to use this software or hitting hardware limits with inefficient software. Received the same "too many options / I don't like it". Meaning becoming unable to use Bind unless making an own installer. It's frustrating since the ports are meant to install software, and nice for doing so. Anyway, I just made a patch to accomplish what was desired in #253480 Turned out to be identical with what was submitted. Testing in Poudriere (starting from zero) costed me half a day, while having a 16 core CPU. So, contrary... stand in the maintainers shoes for a while... It's timeconsuming and sometimes indeed complicated. I understand both parties arguments: look at the dependencies: at least 142 packages by default when you start from zero... (of which a whole bunch that are simply ridiculous for running a DNS daemon). Then yes, you would wish to keep things minimal. But that's actually an argument in favor of what the reporter is asking! (or better in plural: what reporters are asking). Since [a] libxml2 is by default not required and [b] maintainer wish to keep things simple, I suggest -unless selected by user- to actively prevent it -also at dns/bind916-, using '--without-libxml2' since the default is 'auto' (not 'no' as -maybe- suggested above). I just tested both dns/bind916 and dns/bind918 with this, and both went fine. Creating a separate port to accomplish this, doesn't seem a wise way to me.
Well, another option we have is to create two flavors of the dns/bind* ports: - with libxml - without libxml And that requires patching of the dns/bind*.
Created attachment 234348 [details] bind918 with more options Then you basically will have duplicate ports, and so will create double maintenance tasks. But besides --without-libxml2 If I'm authoritative, and for example I don't want DoH --disable-doh and therefor wish to be --without-libnghttp2 which is now not optional AND comes with LIB_DEPENDS=libnghttp2.so:www/libnghttp2 Further there is --enable-dnsrps which is neither optional, but in my case I could --disable-dnsrps --disable-dnsrps-dl 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 --disable-dnstap and actually -in my own usecase- even --without-readline And usually compression comes with extra overhead, so in case I serve tiny zones for an "Alexa500" domain, then I prefer it --without-zlib To prevent surprises when defaults changes, I think it's wise to explicitly --enable-chroot 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 needs. 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" (minimalistic). 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.
(In reply to Leo Vandewoestijne from comment #7) Thank-you Leo. That's a great patch :) addresses my needs very well ;) and better than editing the Makefile or worse adding to my local.mk LIB_DEPENDS:=${LIB_DEPENDS:Nlibxml2*} USE_GNOME:=${USE_GNOME:Nlibxml2*} ... but that's another story.