A packaging request to split a "dnsutils" or "bind-utils" out of "bind"

[Kelley Cook]

Package Proposal
----------------
I would like to request that eight files in the cygwin BIND binary
package be split off into a new package.

Many linux distributions (At least Fedora, SuSe and debian) have split
the ISC Bind binary package into a pair of rpms, bind and a dependent
usually named bind-utils, though in the case of debian it is named
"dnsutils".  (My bikeshed opinion is that Debian's name is a better
choice)

Regardless of the name, this new small package would be just the
client utilities (e.g. host, dig) while bind contains the server
portions (e.g. named).

Specifically, it should contain:

/usr/bin/dig
/usr/bin/host
/usr/bin/nslookup
/usr/bin/nsupdate
/usr/share/man/man1/dig.1.gz
/usr/share/man/man1/host.1.gz
/usr/share/man/man1/nslookup.1.gz
/usr/share/man/man1/nsupdate.1.gz

FWIW: Fedora contains this same list with the addition of one
configuration file that cygwin doesn't install, /etc/trusted-key.key.
Debian is the same without nsupdate while SuSE chose to include a lot
more binaries, most of which would be useless without named running.

Changes for cygwin
------------------
cygcheck followed by a walk through the setup trees shows this
proposed package with these eight files require five libraries through
three package dependencies.

libidn11
libgssapi3 (implies a bunch of other libraries including libopenssl100)
libxml2 (which implies libreadline7)

As mentioned before, if this change goes into effect, the newly
packaged "bind" would then have to be made dependent on package
"bind-utils".  In addition, though they don't really hurt, this would
allow "bind" to remove the five library dependencies listed above
(libgssapi3, libidn11, libopenssl100, libreadline7, libxml2)

Justification
-------------
Though only a few cygwin users run a local DNS server, many cygwin
users are installing the full suite to get at one or more of these
four small utilities.  Putting them in a bind-utils (or dnsutils)
package would solve this.

Furthermore, for some users, it would give access to these simple
utilities without violating a corporate security policy against
locally installing bind.

I believe this simple change would benefit many of your users.

Thanks,
Kelley Cook