[Resolvconf-devel] Bug#414692: closed by Thomas Hood <jdthood at gmail.com> (Not bugs)
edi at gmx.de
Sun Apr 10 21:29:21 UTC 2011
Actually I considered reopening the bug but I cannot reproduce the
problem after purging the package. Now the original file is stored
as /etc/resolvconf/resolv.conf.d/original and restored when the package
is purged again.
Not sure what went wrong before, maybe something was flawed in the
package's debconf configuration created in 2007.
> Addressing the concrete points in the submitter's most recent contribution:
> 1. Resolvconf overwrites manual resolv.conf.
> Resolvconf overwrites resolv.conf because that is its function.
> It includes a header which lets the administrator know that he
> or she should not edit the file manually. The administrator who
This header does not tell the reader what happened with his/her original
data. Neither does the manpage it refers to. Neither does
Now imagine the fun which somebody might have on a network without DHCP
and without a backup of the system config at hand. Luckily, 126.96.36.199 is
easy to remember.
> prefers to edit /etc/resolv.conf manually should either uninstall
> the resolvconf package or replace the symlink at /etc/resolv.conf
> with a file. If /etc/resolv.conf is a file then resolvconf will
> not change it.
As long as it works, fine.
> 2. Resolvconf fails to insert custom servers from dns-up entries
> of /e/n/interfaces.
"dns-up" was just a mistake while writting the previous mail and refered
obviously to dns-nameservers. So: yes, dns-nameservers was used.
And it did not the right thing, the arguments were never added to
resolv.conf contents. Guess why the shell trace log was posted.
> The submitter is a Debian Developer which means that he must be an
> extremely knowledgeable and capable programmer. In the face of
In first place, "the submitter" does respect Debian's social contract,
and sometimes considers anti-user-friendly software a violation of SC.
To change the situation, a verbose/debug mode in resolvconf would be a
useful addition. That's something many essential config tools provide
and "the author" of resolvconf might consider joining the company.
> unexpected behavior exhibited by a package he is capable of analyzing
> the problem and suggesting specific solutions... even implementing
> them! That kind of positive contribution is what I expect from him
> in the future.
"The submitter" also expects other to post meaningful explanations into
BTS before silently tagging bugs with wontfix and letting them rot for
More information about the Resolvconf-devel