On Mon, Sep 13, 2021 at 04:05:57PM -0700, Don Armstrong wrote: > On Fri, 10 Sep 2021, Adrian Bunk wrote: > > On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote: > > >... > > > 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. > > > > How libraries implement a standard high-level C interface is not > > necessarily relevant for how a DNS library implements a low-level > > interface. > > It seems to me that upstream should just not raise > NoResolverConfiguration, and instead not configure any nameservers. > > Then, if someone tries to resolve without any configured nameservers, > NoNameservers will be raised, which is the same thing that happens if > there are no good nameservers, and is less inconsistent with the > previous behavior.
I would consider it worse if init of a module returns success in a situation where it is known that the whole module is nonfunctional, and then returns an error every time a thread tries to use the module. There are obviously several options what could be done, but it's difficult to call the current behaviour a bug in a DNS module. The large picture is that there is no piece of software involved in all this that is clearly buggy itself, the problem is that all pieces together are at the border of forbidden "uses network" in Debian builds. My personal stake in all this is that I've raised the topic twice with Mattia since it makes it a lot harder to use reproducible for finding FTBFS, and I was initially making the case for having the IP address of a non-existing nameserver in /etc/resolv.conf in the reproducible environment. My impression of this discussion is that unless someone discusses and convinces an upstream to change their (not obviously buggy) software, the affected packages must not run these tests during the build and if there are autopkgtest they must have a "needs-internet" restriction. cu Adrian
