[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
/usr/share/doc/resolvconf/README.gz.

Now imagine the fun which somebody might have on a network without DHCP
and without a backup of the system config at hand. Luckily, 8.8.8.8 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
YEARS.

Regards,
Eduard.





More information about the Resolvconf-devel mailing list