Hello Jóhann,
I am packager of BIND in RHEL and Fedora. I would like everyone would
use our BIND packages. But we have some modifications, as was already
mentioned. Some of them are important for FreeIPA to work, some provide
bind-sdb build to use SDB features. Also some other changes that bound
dhcp package to bind libraries. The story short, our package is mostly
the same, but with nontrivial differences.
On 9/30/19 1:11 PM, Jóhann B. Guðmundsson wrote:
https://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.
Bind is already package and maintained in Fedora [1] and derivatives as
well as ISC having it's ownspecific copr repo [2] in addition to that.
Copr exist to overcome limitation in RHEL/CentOS as in RHEL/CentOS
consumer wanting newer release then what's available in RHEL/CentOS
while Fedora packages residing in copr repo would under normal
circumstance only be needed to provide early testing of branches not yet
suitable for rawhide ( read as 9.15.x branch of Bind would be made
available in copr for Fedora while 9.14.x is what should be shipped in
$CURRENT Fedora releases ).
Copr is used also for Fedora, usually testing rebases or preparing
packages that would not be useful for general audience. Or not yet ready
in good enough quality.
It is used for example for my build of 9.14 [3]. Unfortunately my build
fails to run on both normal variant and bind-pkcs11, which FreeIPA
requires. Until I fix it, new version would not be in Fedora. And
bind-sdb variant is turned off as well.
Now the fact that the copr repo contains newer release of Bind compared
to what's currently being shipped in Fedora indicates that there is some
friction between the Fedora maintainer ( which in this case seems to be
a Red Hat employee not an upstream ISC maintainer ) and ISC community
about maintaining Bind in the distribution.
I hope there is no friction. I admit I had not enough time to finish
rebase of 9.14, Fedora still contains last 9.11 release. We decided long
ago to use bind dynamic libraries from DHCP. However, support for
singlethread libraries was dropped in 9.13. Sharing these libraries was
intended to save our maintenance for separate libraries. But now it
proved opossite. That was changed in Fedora 30, where dhcp again uses
original bind library shipped by ISC with it. Now just PKCS11 and SDB
variants are blocking new version.
Unfortunately, I am busy with some internal tasks, so I still had not
time to switch onto BIND 9.14 in Fedora, not even in Rawhide. Sorry for
that. That is all my fault, ISC is not involved anyhow.
On the other hand, having vanilla ISC package available is good. I can
test issues in vanilla ISC package and compare them to Fedora package. I
have plans to reduce differences to necessary minimum. But have more
important tasks for RHEL now. Sorry for keeping you waiting. It is on my
TODO list.
That said removing patches implemented by Red Hat for Fedora or it's
derivative ( RHEL/CentOS etc ) is usually not a smart thing to do and or
not working with upstream community ( ISC ) to provide and help maintain
releases for specific platform or downstream distribution in a package
repository maintained by ISC and it's community ( be it a copr repo or
repository hosted under the isc domain ) will only cause confusion and
frustration of consumers of ISC components at the cost of the
upstream/downstream community surrounding the relevant components.
That said and given that there is no rocket science involved with
removing patches and building packages I ask...
Well, this is more on side of Red Hat adding those patches on top of ISC
sources. I already mentioned few features that needs them. In general,
we at Red Hat try to push as much changes upstream as possible. BIND is
not great example, as its customization contains lot of changes. And we
support more combinations for each build. That also complicates new builds.
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 )?
I think its purpose is to support just their own bugs, not Red Hat bugs.
And to provide ready to use packages soon after release. It is more
difficult for me to follow. As soon as normal variant is able to support
both SDB and PKCS11 variant by configuration/plugin, it should be easier
to maintain and release new version. I think we have an agreement in
that with ISC developers.
Regards
Jóhann B.
1. https://koji.fedoraproject.org/koji/packageinfo?packageID=314
2. https://copr.fedorainfracloud.org/coprs/isc/
Regards,
Petr
3. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.14/
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com PGP: 65C6C973
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
