Spec URL: http://labs.linuxnetz.de/bugzilla/bind-libbind.spec SRPM URL: http://labs.linuxnetz.de/bugzilla/bind-libbind-9.3.3-1.src.rpm BIND (Berkeley Internet Name Domain) includes a resolver library (routines for applications to use when interfacing with DNS), the libbind resolver library compatible with that from ISC BIND 8. This package is going to be branched only for EPEL 4, as libbind doesn't exist there, but one of my packages should depend on it. EPEL 5 and all current Fedora releases are shipping libbind inside of the bind package. I choosed the libbind version from RHEL 5 to have a long update support and maybe some help from Adam Tkac, if needed. As per his suggestion, it is better to put this in EPEL 4, as RHEL 4 only should get bug fixes and no enhancements.
I recommend use bind-9.3.5 codebase (ftp://ftp.isc.org/isc/bind9/9.3.5/bind-9.3.5.tar.gz) because 9.3.3rc2 has flaw (CVE-2008-0122). If you use 9.3.5 you have to drop "libbind-9.3.1rc1-fix_h_errno.patch" because it is included in 9.3.5 (in some different way)
Thanks Adam for pointing out that. Updated package as below: Spec URL: http://labs.linuxnetz.de/bugzilla/bind-libbind.spec SRPM URL: http://labs.linuxnetz.de/bugzilla/bind-libbind-9.3.5-1.src.rpm
Looks good, just some IMHO odd things I'd like to mention/discuss before we move on: * Quoting from the initial comment in this bug: >I choosed the libbind version from RHEL 5 to have a long update support >and maybe some help from Adam Tkac, if needed. As per his suggestion, it >is better to put this in EPEL 4, as RHEL 4 only should get bug fixes and >no enhancements. Well, if this is for EPEL4 why didn't you use the bind from RHEL4 as base, as it has "long update support" as well? I tend to say it will looks quite odd for users to find bind-9.2.4 in RHEL4 but a libbind that's based on the RHEL5-version bind-9.3.5 in EPEL4. Are they really independent/will libbind from bind-9.3 work fine with bind-9.2? * Minor: Might be wise to add a version number or something to this (but okay, maybe none is used in the bind package from RHEL5, so feel free to ignore it) : Source1: libbind-man.tar.gz * Specifying glibc-devel should not be needed, as gcc likely depends on it: BuildRequires: glibc-devel >= 2.2.5-26, glibc-kernheaders >= 2.4-7.10 * The "description" is IMHO confusing/hard to read and doesn't really express what the package contains. * This "(-,root,root)" IIRC should be "(-,root,root,-)" * rpmlint silent
> Well, if this is for EPEL4 why didn't you use the bind from RHEL4 as base, as > it has "long update support" as well? I tend to say it will looks quite odd > for users to find bind-9.2.4 in RHEL4 but a libbind that's based on the > RHEL5-version bind-9.3.5 in EPEL4. Are they really independent/will libbind > from bind-9.3 work fine with bind-9.2? AFAIK libbind found it's way into Fedora/RHEL the first time with a bind 9.3.x series, I can imagine this had a good reason. On the other hand, the bind 9.2.x ships libbind.so.3 which seems to be a bigger step to libbind.so.4 coming from 9.3.x; the current bind 9.5.x also ships libbind.so.4. This keeps me as EPEL maintainer on the safer side, that if something in libbind breaks, somebody has at least a look for RHEL 5 at it and I can just grab/steal afterwards the patch for EPEL 4 ;-) Personally, I didn't see a problem with having this libbind packageon a CentOS 4.6 together with Bitlbee 1.2, yet. Ah and a closed source third party software also works with it - oh and that one somehow depends on libbind.so.4 and not on libbind.so.3... But regarding the real deep technical points, maybe Adam is able to tell a few words here? > Source1: libbind-man.tar.gz I'll change that. I just copied it over from a current bind package as it is. > BuildRequires: glibc-devel >= 2.2.5-26, glibc-kernheaders >= 2.4-7.10 I think, you're right. Also a copied thing. I'll check this soon for the next package in mock. > * The "description" is IMHO confusing/hard to read and doesn't really express > what the package contains. Mmmh...yes. Should get rewriten, when now re-reading it again. > * This "(-,root,root)" IIRC should be "(-,root,root,-)" Luckily that's optional and not a must ;-)
(In reply to comment #3) libbind compiled from RHEL4 bind package should not be used because it is not supported and it contains many bugs (at least CVE-2008-0122 as I wrote above). Best should be use libbind based on RHEL5 package or on 9.3.5 release (I prefer 9.3.5 because it contains some additional bugfixes)
Okay, updated package as below: Spec URL: http://labs.linuxnetz.de/bugzilla/bind-libbind.spec SRPM URL: http://labs.linuxnetz.de/bugzilla/bind-libbind-9.3.5-2.src.rpm
Looks fine for me, reviewed.
New Package CVS Request ======================= Package Name: bind-libbind Short Description: Berkeley Internet Name Domain (BIND) libbind resolver library Owners: robert Branches: EL-4 InitialCC: Cvsextras Commits: no If somehow possible, PLEASE DO NO BRANCHING FOR DEVEL, JUST EL-4! As spoken in this bug report, libbind is included in bind package on EL-5+/FC-6+ and thus a devel branch won't be ever needed.
Alas, there is no way to do that. devel branch is required for all packages. ;( You should simply go and add a 'dead.package' file to your devel branch that contains a pointer to the EL-4 branch and why the devel branch is dead. cvs done.
38909 (bind-libbind): Build on target fedora-4-epel succeeded.