Red Hat Bugzilla – Bug 57489
Old man page for dig and nslookup
Last modified: 2007-04-18 12:38:42 EDT
Description of Problem: The man page for dig and nslookup is from August 30, 1990. The man page for nsupdate and host is from 2000. Version-Release number of selected component (if applicable): bind-utils-9.1.3-4 How Reproducible: man dig (press SHIFT+g) man nslookup (press SHIFT+g) ;-) Actual Results: 4th Berkeley Distribution June 24, 1990 4th Berkeley Distribution Expected Results: BIND9 9 Jun 30, 2000 BIND9 9
Well, since the bind package doesn't provide a man page for nslookup (probably because they consider it to be a deprecated program and want to discourage people from using it), it's probably a good thing that Red Hat provides a man page (albeit outdated) for it; AFAICT, the outdated man page still matches current versions of nslookup(8) pretty closely, and the nslookup program in bind9 doesn't have any built-in documentation. However, since at least bind 9.1.0 (and perhaps older versions), bind *does* actually ship with an up-to-date man page for dig(1). Red Hat's bind package is stomping bind's dig(1) man page with its own, outdated man page. Bernhard: please, please, please dike dig.1.gz out of bind-manpages.tar.bz2 and release an errata update for bind (for all affected Red Hat releases). The dig.1.gz in bind-manpages.tar.bz2 is so outdated (w/respect to the dig program that ships with bind9) that it's leading people astray.
Oops. I realize now that bind-manpages.tar.bz2 package might be coming from (or partially from) the ISC, because Jim Reid mentioned on the bind9-users mailing list that in BIND8, the man pages were in a separate tarball from the sources. Bernhard: Jim Reid also said that if Red Hat is writing man pages for bind, they would appreciate it if Red Hat would feed those man pages back to the ISC. Just FYI...
This problem has been fixed for Red Hat 7.3. Specifically, the dig(1) man page that comes with bind9 is no longer overwritten with the dig(1) man page from bind-manpages.tar.bz2. Is there any reason why this bug shouldn't be closed with CURRENTRELEASE?
no, there's no reason. Closing now