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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
