bind-tools bloat

[pjp]

Has anyone tried using bind9-dnsutils from Debian, or another format from somewhere else? Or perhaps an overlay that uses such a package? (I can't tell what the eras-overlay does).

https://packages.debian.org/bookworm/bind9-dnsutils

[sam_]

Binary distributions have the advantage of being able to build something once from source and then split up the resultant image (even with hacks) and it being normal in their culture.

The eras-overlay version, AFAIK, simply does what the old bind + bind-tools ebuilds did but with more hacks because of the aforementioned changes entrenching the tools. You're free to use that, or binaries from Debian, if you wish, but I maintain that it's essentially snakeoil to do so given the same library code is there, even. Just INSTALL_MASK if it bothers you, but then the onus is on you to not exclude any necessary files.

I'll also note a point I don't think I made earlier -- one of the big issues with the lack of build system support for this split means you need any and all dependencies the main build needs, you can't divide it into just the tools dependencies.

[pjp]

Binary distributions have the advantage of being able to build something once from source and then split up the resultant image (even with hacks) and it being normal in their culture.

Thanks for reminding me of that. I "know" it, but don't always think of it. My initial reaction was "I wonder what the problem is... binary distros seem to still be doing it."

[mkrsn]

Because this is still an issue (and this thread one of the first google hits) I tried to figure out howto clean that damn bloat up.
Only using INSTALL_MASK isn't enough. It's also necessary to skip the pkg_postinst phase. Otherwise emerge will explode.

It took me ~2 hours to figure this whole topic out. Hopefully, I can save someone else that time.

Code: Select all

root@client02 ~ $ cat /etc/portage/env/net-dns/bind 
INSTALL_MASK="/etc/*"
INSTALL_MASK="${INSTALL_MASK} /usr/bin/dnssec-* /usr/bin/named-* /usr/bin/nsec3hash /usr/bin/nslookup"
INSTALL_MASK="${INSTALL_MASK} /usr/include/*"
INSTALL_MASK="${INSTALL_MASK} /usr/lib/*"
INSTALL_MASK="${INSTALL_MASK} /usr/lib64/bind/*"
INSTALL_MASK="${INSTALL_MASK} /usr/libexec/*"
INSTALL_MASK="${INSTALL_MASK} /usr/sbin/ddns-confgen /usr/sbin/named /usr/sbin/rndc-confgen /usr/sbin/tsig-keygen"
INSTALL_MASK="${INSTALL_MASK} /var/*"

pkg_postinst() { return; }

[Hu]

This will remain an issue (at least) until upstream offers a build system that makes it straightforward to build and install only what is needed for a given purpose. sam_'s first post in this thread addresses some of that, and sam_'s third post describes why trimming is a fragile nuisance with the current upstream build setup.

The installed package is ~7MiB here, with no install masks. Using masks only saves on installed disk space, but does not let you avoid installing the dependencies required for components you ultimately mask out. In principle, it would be nice to not spend disk space on parts that are not needed. In practice, for a typical Gentoo desktop system, 7MiB is a rounding error (and saving the full 7MiB means nothing is installed, so a correct set of masks will save less than 7MiB). Careful masking could be useful on a severely space constrained system.

Personally, I would consider nslookup part of the client tools and worthy of not being masked. Conversely, I would've masked out the manual pages for the binaries that were masked out.

[Zucca]

Also even if one sets the install masks, the compilation process still builds all components, thus wasting CPU time. I don' think insufficient disk space is an issue here, even on low end machines.

If I have understood correctly upstream doesn't have separate "make targets" for tools/utils and server.
So to really have this problem properly solved, one would need to patch some files to have separate build instructions for each of the parts.

And when it comes to making this happen (in my understanding) one would need to "fight upstream" every time the package gets updated. This means creating a new patch for each release.

I think most sane way would to convince upstream to have an option only to "make tools".

[Hu]

The CPU time spent building is unfortunate, but that's not a regression relative to bind-tools. As I understand it, the bind-tools ebuild built everything (because that's the only thing upstream supports), then selectively installed the useful bits. In effect, the Gentoo developer maintaining bind-tools kept a central equivalent of INSTALL_MASK - and the process was fragile enough that it was abandoned. Switching to the combined ebuild doesn't use meaningfully more CPU time than letting the old bind-tools ebuild build everything and discard unwanted bits. The disk usage is a regression relative to bind-tools, though in my opinion, not enough of one to worry much.

[pa4wdh]

My preferred way would be to have USE="server" for bind package. But if that could possibly cause a lot of breakages, then better to just go "all-in" and have the server stuff come along. I know some people like to drop all the unnecessary bits off to limit possible attack vectors...

I haven't dug enough deep to say which is the better option from packager's perspective, so I trust sam_ on this.

That seems a bit strange to me. BIND (Berkeley Internet Name Daemon) is actually the server package, so making the server optional is a bit like "Lets install sys-kernel/gentoo-sources, but don't install the kernel sources".
The "old" way with two packages for tools and the server was cleanest, but for now i accept the server as unnecessary install since i really like the tools, especially dig.

[Zucca]

...i accept the server as unnecessary install since i really like the tools, especially dig.

Just like I do. ;)

BIND (Berkeley Internet Name Daemon) is actually the server package

Maybe upstream should create another project: BINT. ;)

[Anon-E-moose]

If I have understood correctly upstream doesn't have separate "make targets" for tools/utils and server.
So to really have this problem properly solved, one would need to patch some files to have separate build instructions for each of the parts.

Well, they do set things up by bin files

Code: Select all

$ cat /etc/portage/patches/net-dns/bind/bind-tools.patch 
--- a/bin/Makefile.am	2025-11-07 06:29:54.596158548 -0600
+++ b/bin/Makefile.am	2026-01-20 11:04:09.781429877 -0600
@@ -1 +1 @@
-SUBDIRS = named rndc dig delv dnssec tools nsupdate check confgen tests plugins
+SUBDIRS = dig delv dnssec nsupdate check confgen tests

Just a quick test on my end, create an image dir, but didn't load to system, of course all libs, etc get built.
Binaries under named, rndc and tools didn't get built/compiled nor put in the image (pre-install to system)

Not conclusive, but with a little work tools could be done without named, or for example, you just wanted dig, the dig dir creates, dig, host and nslookup get built
I'm not that interested in chasing it down as I use unbound and dnsmasq, I do use dig, etc, but it's an older version, that still works well.
But it's something to look at for feasibility.

[sam_]

When I last looked, IIRC most of the code was in shared internal libraries, hence not much saved there (and again, you're still maintaining a manual "INSTALL_MASK" list -- either a whitelist or a blacklist of binaries for targets to run). Having SUBDIRS there does not make convenient separate make targets either.

Sure, though, someone could investigate it again to see if either we missed something or if the situation improved. What I'm currently wondering about is, with bind 9.21 (IIRC), they're now using Meson. When porting the ebuild to Meson, we could look at using install tags for components, but the value in this depends again on the internal structure and whether some libbind or whatever is being built regardless.

[RumpletonBongworth]

The (smaller) net-libs/ldns package provides the drill(1) utility, whose functionality is similar to that of dig(1). It is also better implemented, in my estimation.

[dmpogo]

Interesting, for me the most regression is not even extra disk space, but to have entries in /etc/init.d and /etc which correspond to subsystem that is not needed on this machine.
I sometimes consult this directories to see what I may have forgotten to configure or maybe need, and feel better with a shorter list

[nicop]

The (smaller) net-libs/ldns package provides the drill(1) utility, whose functionality is similar to that of dig(1). It is also better implemented, in my estimation.

drill is indeed a great alternative.

When porting the ebuild to Meson, we could look at using install tags for components, but the value in this depends again on the internal structure and whether some libbind or whatever is being built regardless.

Similar case with knot. "net-dns/knot -* utils" installs the tools including kdig but it requires shared libs anyway (libknot.so, libdnssec.so, libgnutls).
Substantially faster here though:
bind-tools : real 1m20.284s / user 3m7.280s / sys 0m34.657s
knot -* utils : real 0m26.309s / user 0m48.040s /sys 0m12.753s

[logrusx]

Interesting, for me the most regression is not even extra disk space, but to have entries in /etc/init.d and /etc which correspond to subsystem that is not needed on this machine.
I sometimes consult this directories to see what I may have forgotten to configure or maybe need, and feel better with a shorter list

That's easy. Add an install mask for that and you're good to go.

My solution:

Code: Select all

emerge --deselect bind-tools
emerge --noreplace bind
emerge -ca

End of story.

Best Regards,
Georgi

[Zucca]

• • • FYI:

Development Vision

ldns has been in maintenance mode since 2020.

In principle we only perform basic maintenance and bug fixes on ldns. This could for example be for a research project or an IETF Hackathon. We do not strive for ldns to be a comprehensive library that supports every (emerging) standard.

Successors

• The natural successor to the ldns library is the domain library for Rust
• We offer drop-in replacements for commonly used ldns example utilities in dnst
• ldns includes a DNS lookup utility named drill. We have reimagined the functionality and output of such a DNS inspection tool in dnsi, with a focus on usability.

[nicop]

ldns has been in maintenance mode since 2020.

Yes, but releases, PR merged, bugfixes...

[sam_]

That said, we may want to package these new tools, even if they are Rust. But I'm happy with drill.

[Zucca]

ldns has been in maintenance mode since 2020.

Yes, but releases, PR merged, bugfixes...

Yes. I didn't mean it was unsafe to use it, just that there is no "motivation" for adding new features to ldns, but rather to other tools mentioned in the message.
Although when it comes to such tools as dig and drill, maybe those don't need any more features and are thus "ready"...

[Ralphred]

Even the entirety of bind is a very small package, I understand sam_'s reticence to over-complicate the official ebuild(s) - this smells like a net-dns/dig::guru solution to me.