Mattia Rizzolo wrote: > during the year, a src:dnspython change made it so that any software > importing that library now requires a valid /etc/resolv.conf with at > least one nameserver configured. > > This also made it so that something between 50-100 packages now fail to > build if the build system doesn't have any working /etc/resolv.conf. I > venture to say that this is a very reasonable configuration to have in a > build system that tries to be network-disabled. > > It must be noted that no actual network operation happen, so this > doesn't fall into the "no network activity" bucket. > > > This is the bug that was filed against dnspython: > https://bugs.debian.org/989171 > > > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment?
I think dnspython's previous approach was correct: just like glibc, musl, and other libraries, if /etc/resolv.conf is missing they should treat that as though it specified a nameserver on localhost. The change to make that a configuration error, instead, breaks real configurations that intentionally don't have /etc/resolv.conf. Among other things, having a DNS server on localhost (or forwarding the DNS port on localhost to your real DNS server) means that a chroot without /etc/resolv.conf still has functional DNS. Now, that said, if the build process actually wants a DNS server to run tests against, it should provide or depend on such a DNS server, and configure it for such tests. But a build process that's just *importing the dnspython library* should not need to have either /etc/resolv.conf *or* a functional DNS server. - Josh Triplett
