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

[Tomek Mrugalski]

On 12-02-16 06:37, Naoki Kambe wrote:
> Jeremy-san,
> 
> Can I add just two minor comments to your suggestions?
> 
> If we separate auth from stats, we may disable periodical sending
> of statistics data in auth.
> 
> b10-stats-httpd cannot work independently without b10-stats, so the
> package of bind10-stats-httpd should have a dependency to
> bind10-stats.
> 
> Thanks,
> 
> Naoki Kambe
> 
> 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.
>>
>> A few years ago, we discussed about having different source packages 
>> (with own configure and install steps for example) but decided to not do 
>> it yet due to rushed prototype development work.
>>
>> We should decide how we want to do this, we don't want different 
>> packages to re-invent steps for this.
>>
>> Some ideas include:
>>
>> - separate source packages for libraries and different components which 
>> may involve major restructuring of the source repo.
>>
>> - configure switches to select what components are built and installed
>>
>> - same build regardless, but different make targets for specific 
>> installs
>>
>> Also need to decide how far to break it down; here are some suggestions:
>>
>> bind10-core: msgq, cfgmgr, boss, sockcreator, related python modules, 
>> libexceptions, and libcc.
>>
>> bind10-control: bindctl, cmdctl, related python libraries
>>
>> 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.

>> bind10-dnslibs: libdns++, libdatasrc, libacl, etc.
>>
>> bind10-auth: b10-auth, b10-xfrin, b10-xfrout
>>
>> bind10-resolver: b10-resolver
>>
>> bind10-stats: b10-stats
We haven't talked about stats yet in DHCP context, but I suppose we will
use the same mechanisms as DNS, so there is no need to split this into
stats-dns and stats-dhcp.

>>
>> bind10-stats-httpd: b10-stats-httpd
>>
>> bind10-dhcplibs: libdhcp++
Currently we do not plan any additional DHCP-specific libraries.
Anything DHCP-related that could be called library will be part of
libdhcp++, so this packet could be called bind10-libdhcp++. I don't have
any strong preference, though. bind10-dhcplibs name has the advantage of
being included with bind10-dhcp* wildcard.

We do plan to eventually have hooks, together with examples and sample
implementations. I think they should be packaged separately, as their
use cases are different that the lib itself. But again, we haven't given
much thought, so we may decide to bundle it together with libdhcp
package. I'm mentioning that in case you want to also list potential
future packages. In that case, I would call it bind10-dhcphooks.

>>
>> bind10-dhcp6: b10-dhcpv6
bind10-dhcp4 is currently available as well. It is still only a skeleton
server, but user can run it and it will be able to assign a single lease.

Which package would include DNS Update support? That is something that
we will definitely use in DHCP.

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.

Tomek