[Resolvconf-devel] Re: maintaining resolvconf

[Eric Evans]

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
it.

I had to go back to the email you referenced[1] 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 
across upgrades.

> 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
part correctly.

> 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.
> 
> Thanks
> 
> -- 
> 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. :)


[1] http://lists.alioth.debian.org/pipermail/resolvconf-devel/2006-April/000023.html

-- 
Eric Evans
eevans at sym-link.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/resolvconf-devel/attachments/20060703/627cf12e/attachment.pgp