Diary of a geek

April 2009
Mon Tue Wed Thu Fri Sat Sun
    5
     

Andrew Pollock

Categories

Other people's blogs

Subscribe

RSS feed

Contact me

JavaScript required


Sunday, 05 April 2009

DHCP package futures, the braindump

Now that Lenny is released, I've got some time to go to town on the ISC DHCP packages.

The first thing I want to do is get DHCP 4.1 uploaded. Unfortunately, this first requires a bunch of transition work, and the associated coordination that goes with it. This post is an attempt to marshal the stream of consciousness and come up with a plan...

Problem #1: everything has 3 in it

The packages themselves need to lose the 3 everywhere. The source package is dhcp3. That seems kinda retarded if its DHCP 4.1.0. The binary packages all need to loose the 3 as well.

apt-cache rdepends dhcp3-client tells me I'll need to reach out to the maintainers of the following packages:

avahi-autoipd
wifi-radar
synce-hal
rutilt
rootstrap
resolvconf
nfsboot
lxnm
laptop-net
ifupdown
education-desktop-other
dhcdbd
bpalogin
avahi-autoipd

Obviously I can keep the old packages around for a while for transitionary reasons.

The 3's also persist in various directories provided by the packages: /etc/dhcp3, /var/lib/dhcp3

apt-file search /etc/dhcp3 tells me I need to reach out to the maintainers of the following packages:

avahi-autoipd
debian-edu-config
debian-installer
dhcdbd
fai-doc
fai-nfsroot
ntp
ntpdate
resolvconf
samba-common
sendmail-base
whereami

Obviously I can keep some compatibility symlinks around for a transition period.

Problem #2: the names themselves

Is it right to monopolise the name "dhcp-client" or "dhcp-server"? I tend to think not. So should I rename the source package to "isc-dhcp" and prefix all of the binary packages with "isc-"? I think this would cleanly address #520842 and the fact that there's apparently supposed to be a "dhcp-client" virtual package.

Problem #3: dhclient-script is old and crufty

This is less pressing, and less packaging related, but the dhclient-script we ship now is Debian-specific. There is room for optimisation, and there are better ways to implement the script so it's more externally customisable. I'd also dearly love to switch over to using iproute for everything possible.

This brings us to the game plan, which I think I'll write in a future post after I've meditated on the problem a bit, now that I've finally written it all down...

[00:10] [debian] [permalink]