[bind10-dev] splitting up BIND 10 to install different features

[Stephen Morris]

On 16/02/2012 12:24, Tomek Mrugalski wrote:
>> 
>> From: "Jeremy C. Reed" <jreed at isc.org> Subject: [bind10-dev]
>> splitting up BIND 10 to install different features Date: Wed, 15
>> Feb 2012 10:23:06 -0600 (CST)
>> 
>>> I had a package reviewer request splitting up the package into
>>> separate packages for different features, like core, auth
>>> server, resolver.

I'm all in favour of that; it will make life easier if all you want to
do is run one component (e.g. bind-10 dhcp) as you won't need all the
other components and their dependencies.  I think it will also make it
easier for people to write other modules that fit into the BIND 10
framework.

>>> bind10-libs: libcfgclient, liblog, libstatistics, and other
>>> libraries
> Does it make sense to split bind10-core and bind10-libs? If these 
> libraries are needed all time (like liblog), perhaps those two
> could be merged.

I think it make sense if the libraries can be used independently of
the rest of bind 10.  If not, there is no reason for the split.

> I think it would be reasonable to add bunch of --enable-X,
> --disable-X switches to configure script. A good example would be a
> case when someone wants to compile DHCP only, so all DNS goodies
> would NOT be configured. That is also important from the
> dependencies perspective, e.g. botan is not required for DHCP.

That might be simplest, although there may be potential problems, e.g.
if I --enable-auth (for example) would that mean I automatically build
core?  And if I do, what if I want to install auth in one place and
resolver in another - do I end up with two copies of the libraries?
(Why anyone would want to do that is another matter, but you can be
certain that if it is possible, someone, somewhere, will do it.)

I can't help feeling that treating the different packages as separate
products (each with their own source tree) will end up being the
easiest way handle this. Although some overarching way of making
everything in one command - perhaps a special configure script with
the --enable-X and --disable-X options described above - will be needed.

Stephen