[Resolvconf-devel] Re: maintaining resolvconf
eevans at sym-link.com
Mon Jul 3 23:16:49 UTC 2006
I assert that Thomas Hood said the following on Wed, May 03, 2006 at 08:22:08AM +0200:
> Eric Evans wrote:
> > Sure, I'll have a look at it.
> OK. The author's package might contain some ideas with enough benefits
> to outweigh the pain and risk of making changes to Debian resolvconf,
> which is currently working well. I am not too impressed with the fact
> that he doesn't use temporary files. Use of temporary file and "mv"
> makes the replacement operation atomic, which is important.
Sorry it took me so long to respond to this. I did take a look back in
May, (0.3 at the time), but for some reason never managed to put an
email together. So, I pulled down Roy's latest today, (1.0), and went
over it again.
The question I had back in May, and that I found myself asking again
today was, "why?". It strikes me as a re-implementation for the sake of
I had to go back to the email you referenced to get an idea of what
might have motivated him to start over. I've reposted it here and
added some comments in-line.
> -------- Original Message --------
> Subject: resolvconf in Gentoo
> Date: Sat, 8 Apr 2006 01:56:04 +0100
> From: Roy Marples <uberlord at gentoo.org>
> Organization: Gentoo
> To: jdthood at yahoo.co.uk
> Hi Thomas
> I'm a maintainer of Gentoo baselayout - basically the system init scripts.
> I've taken your resolvconf package and given it a thorough revamp for gentoo
> and pure bash (no temp files used) whilst keeping the original concept and
> config intact.
The elimination of temporary files seems to have been one of the primary
motivators. I'm not sure why this was a problem, and as you already
stated, this comes at the expense of losing atomic file replacement.
> The only thing left intact is the man page - lol. On the man
> page I've said it's written by me and based very heavily on your work. I hope
> this is OK, if not let me know and I'll change it.
> The Gentoo version relies on a baselayout provided generic script to provide
> the uniqify function (echoed as a string instead of a fixed var) and
> einfo/ewarn/eerror functions to provide pretty printing and logging. However,
> these are trivial to remove / add to resolvconf directly.
> Also, resolvconf is self contained in Gentoo - there is no listinterfaces or
> other external stuff.
It is definitely more self-contained, but I don't think this is a change
for the better. As an example, while I've never done so, I see it as a
feature that you can edit interface-order and have your changes preserved
> Lastly, the files in update.d (not provided in the gentoo ebuild, they will
> be punted to the proper ebuilds (dnsmasq, bind)) don't create temporary files
> and they also work in a nicer way. Basically DHCP clients always set their
> domain(s) in the search field, whereas it's trivial to set openvpn's to the
> domain field. So we make the assumtion that a "search" directive means it's a
> generic nameserver and a "domain" directive means it's a namesever purely for
> that domain. libc just takes the lot and stops at localhost, but this new way
> for dnsmasq and bind works really well for me using openvpn.
This bit is either clever, or totally wrong. I'm not sure I grok this
> The package is available at http://dev.gentoo.org/~uberlord/resolvconf-gentoo/
> Just a FYI and thanks for a great idea. If you're interested in incorporating
> my stuff, let me know.
> Roy Marples <uberlord at gentoo.org>
> Gentoo Linux Developer
In summary, I didn't find anything that would meet the "...enough
benefits to outweigh the pain and risk of making changes to Debian
resolvconf..." criteria. :)
eevans at sym-link.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/resolvconf-devel/attachments/20060703/627cf12e/attachment.pgp
More information about the Resolvconf-devel