RHEL, Centos, Fedora rpm 9.14.6

[Victoria Risk]

> On Sep 30, 2019, at 7:08 AM, Lightner, Jeffrey <JLightner at dsservices.com> wrote:
> 
> I can't speak for him but will say Carl has been providing these packages and announcing them on this list for quite some time now and it is valuable to those who would like to use later upstream packages on RHEL/CentOS/Fedora.
> 

I would like to add that ISC very much appreciates Carl’s work over the years packaging BIND for CentOS users. He has been meticulous about updating his packages promptly every time we have a CVE and I expect quite a few users have come to rely on his packages. ISC only recently began providing packages.  I reached out to Carl at the time we were planning the ISC packages for advice, because of his experience. 


> What's the purpose with these builds, what problems do they solve which are unsolvable with upstream ( ISC ) or downstream ( Fedora/RHEL/CentOS
> ) and why announcing you are building it and how long are you intending to supporting those builds ( encase someone decides to use those builds instead of ISC or downstream distribution maintained ones )?

The ISC packages are different from Carl’s CentOS package and the official RedHat packages in several ways:
- the ISC packages start from the ISC tarball, and do not incorporate any additional downstream RedHat bug fixes.  (I believe Carl’s packages are also built this way.)  ISC can’t support the RedHat packages because they have different code, and different bugs from the official ISC releases. 
- the ISC packages provide the most up to date BIND versions. The RedHat support policy does not allow them to update applications in a stable OS branch.  This is why they cherry-pick things to backport, as Jeffrey explained, but this approach has its limits. (Carl’s packages are up to date, of course.)
- the ISC packages specifically incorporate the additional dependencies required to enable dnstap support. (I don’t know whether Carl’s packages incorporate this or not)

ISC also has respect for and a good relationship with the RedHat team that maintains BIND in the RedHat distribution. We each have our own user base we are responsible for, and we each have different policies about what sort of changes we allow in a stable branch. It is a good thing there are several distributions to choose from when deciding on a BIND package.