ISC DHCP 4.2.0a1 is now available

[Glenn Satchell]

>Date: Mon, 7 Dec 2009 15:28:55 -0800
>From: "David W. Hankins" <dhankins at isc.org>
>
> On Fri, Dec 04, 2009 at 06:11:30PM -0800, Shawn Routhier wrote:
> 
> > The new DDNS code makes use of several BIND libraries.  The tarball
> > includes an appropriate version of BIND and the libraries will be
> > compiled as part of the standard ./configure and make process.  gmake
> > is required to build the BIND libraries.
> 
> I'd like to take a moment to solicit feedback from folks on this.
> Right now we always statically link to the bind export libraries from
> the bind tarball we include in the package, but we'd like to link to
> the export libraries installed from bind9 separately.
> 
> Bind9 doesn't currently install the export libraries automatically,
> and there aren't a lot of other applications that use them...
> 
> Although right now the DHCP software has gotten a bit bigger because
> of including these libraries, this is an opportunity for us to grow
> smaller in aggregate by sharing more code between the two software
> packages.
> 
> So I'd like to know what folks (especially folks who integrate our
> software) think of the current setup on bind9's side
> (bind9-etc/lib/export/), and what would be easiset/most useful for us
> to do on DHCP's ./configure side for finding (and version checking)
> the pre-installed libraries.

I'm a big fan of using shared libraries. Using less memories is an
admiral goal (even in these days of multi GB memory installs).

However, the libraries themselves are not that big. On my Solaris 10
system libbind9.so is 3.5MB. Looking at the running named to get a size
of the memory mapped to these libraries only gives a total under 4MB. I
used pmap to see the memory mapped for each shared lib and added up the
ones in /usr/lib/dns.

There's also a security benefit. Upgrading the bind libraries, say for
a security fix, doesn't require upgrading dhcpd, or any other programs
that use the shared libraries. Tracking down all the apps that
statically link a given library is hard work.

The only disadvantage I can see is making sure dhcpd will work with a
variety of library versions, and hope that doesn't need too many test
cycles or specific code changes. I guess it also needs to deal with the
situation when those libaries are not found or not installed on the
system. Should dhcpd build them as dynamic libs and stash them in a
dhcp specific place? Or mandate that the specific package be installed
as a dependancy?

regards,
-glenn