[Resolvconf-devel] Bug#414692: closed by Thomas Hood <jdthood at gmail.com> (Not bugs)

Eduard Bloch 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, 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 mailing list