Hi LRob, On Sun, Jan 18, 2026 at 04:39:27AM +0100, LRob wrote: > For the record, on my system: > $ aptitude why resolvconf > i isc-dhcp-client Suggests resolvconf
A suggested package would not be installed upon installing isc-dhcp-client. > The core issue: one package should not silently alter another package's > primary behavior. And this is where we disagree. The stated purpose of the resolvconf package is to modify system behavior. This is not new. There are several packages in the archive that perform configuration on other packages. > Regardless of how resolvconf ended up on a system, a recursive resolver > like unbound should not silently become a forwarder. Again, I disagree. If you opt to installing a package whose stated purpose is to configure the resolver to use the servers provided via DHCP/PPP, then yes, I expect it to do just that. > 1. Installing resolvconf is not "opting in" to change unbound's behavior. Yes, it is. It may very well be that your provider would like you to forward your DNS traffic to their resolvers to improve latency (via caches) and reduce their own traffic. They might have opted you in. > 2. Users install resolvconf to manage /etc/resolv.conf, not to turn their > recursive resolver into a simple forwarder. > -> These are two separate intents. I might agree to that. resolvconf mixes both concerns, but then using resolvconf to map /etc/resolv.conf to 127.0.0.1 is a rather boring exercise and you might just edit the file. So the primary purpose of resolvconf is configuring the local resolver and make it forwarding. > As for the captive portal argument: who runs Unbound locally on a laptop? I used to do so. Meanwhile I changed most mobile systems to systemd-resolved. > To sum up: > The current behavior shows little to no benefit while causing major issues. We disagree. > It breaks intended features... And breaks trust for the unbound package. We disagree. > I do trust you'll find the best solution as experienced dev/maintainers. > I have no real preference as long as packages go back to being reliable. I also reached out to other committee members and the replies go into the same direction. Installing resolvconf kinda implies an intention to run a client system (with forwarding). Perhaps the package description of resolvconf could be enhanced, but we feel it does what it should be doing. So the good thing is that we now got to the bottom of the disagreement. Given the replies from other committee members, I suggest that if this were coming to a vote the expected outcome would be declining to overrule the unbound maintainer. Do you want to present any further arguments (that we have not seen yet) in favor of your position? Helmut
