bind9-next-* tries to replace bind-* RHEL 9 packages, which is not allowed for EPEL 9 packages:
$ dnf update
Updating Subscription Management repositories.
Last metadata expiration check: 0:49:00 ago on Mon 30 Jan 2023 12:48:28 PM CET.
Error:
Problem: package private-package-0.0-0.el9.x86_64 requires bind-utils, but none of the providers can be installed
- package bind9-next-utils-32:9.19.9-2.el9.x86_64 conflicts with bind-utils provided by bind-utils-32:9.16.23-5.el9_1.x86_64
- package bind9-next-utils-32:9.19.9-2.el9.x86_64 obsoletes bind-utils < 32:9.17.0 provided by bind-utils-32:9.16.23-5.el9_1.x86_64
- package bind9-next-utils-32:9.19.9-2.el9.x86_64 conflicts with bind-utils provided by bind-utils-32:9.16.23-1.el9.x86_64
- package bind9-next-utils-32:9.19.9-2.el9.x86_64 obsoletes bind-utils < 32:9.17.0 provided by bind-utils-32:9.16.23-1.el9.x86_64
- package bind9-next-utils-32:9.19.9-2.el9.x86_64 conflicts with bind-utils provided by bind-utils-32:9.16.23-1.el9_0.1.x86_64
- package bind9-next-utils-32:9.19.9-2.el9.x86_64 obsoletes bind-utils < 32:9.17.0 provided by bind-utils-32:9.16.23-1.el9_0.1.x86_64
- cannot install the best update candidate for package private-package-0.0-0.el9.x86_64
- cannot install the best update candidate for package bind-utils-32:9.16.23-5.el9_1.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
$
BZ#2161942 Review Request: bind9-next - The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
BZ#2165256 Combined dependencies of bind, bind9-next, and freeipa-server mean system winds up with mix of bind and bind9-next, FreeIPA fails
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Mixing bind9-next instead of normal bind package is an error, hopefully fixed in release 3. It should be alternative version used only when user has chosen to switch to it. It were not intended to replace bind package from CentOS/RHEL and it has to be fixed to not do that. Please check last version does not push itself into your system.
Not fixed. bind9-next-devel still provides bind-devel. That will cause dnf to pull in bind9-next-devel instead of bind-devel causing linking against wrong library.
I'd remove all these provides on epel.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Personally, I'm not sure how to reproduce @tis findings. For me bind9-next-9.19.9-3.el9 does no longer impact the bind packages from RHEL 9 (on a system having EPEL 9 stable and testing repositories enabled).
This package violates EPEL policy. Because bind-next-devel provides bind-devel, anything that build requires bind-devel will get built against this instead of the RHEL package.
@carlwgeorge Have you tried it with enabled (rhel-)CRB repository? dnf builddep bind-dyndb-ldap.spec installed bind-devel-9.16.23-7.el9.x86_64 to me. As did just dnf install bind-devel. Can you provide detailed steps and list of enabled repositories you have tried? It should not replace bind-devel in current build.
EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were built for. Thus packages from EPEL should never replace packages from the target base distribution.
Historically this has been interpreted to include both obsoleting and providing a RHEL package name. I believe this stems from yum behavior, where yum would pick an alternatively named package to satisfy a dependency if it provided the original name and had a higher version. If dnf has changed this behavior, we may need to revist the policy for EL8+.
Please file an issue for the EPEL Steering Commitee and we'll discuss this at the next meeting. Do not push this update to stable in the meantime.
Ah, I see the source of the confusion. The provides in this package do not include the epoch, so dependencies are still resolving to the RHEL package with the epoch.
As a separate test, I built three packages, foo-1-1.el9, bar-1-1.el9, and bar2-2-1.el9. foo requires bar, and bar2 provides bar. With those set up in a test repo, dnf install foo results in foo and bar2 being installed. dnf behavior hasn't changed.
Please proceed with filing that issue so we can discuss it further to see if this should be allowed by policy.
This update has been submitted for testing by pemensik.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
pemensik edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by pemensik.
pemensik edited this update.
This update has been pushed to testing.
bind9-next-* tries to replace bind-* RHEL 9 packages, which is not allowed for EPEL 9 packages:
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
pemensik edited this update.
pemensik edited this update.
Mixing
bind9-next
instead of normalbind
package is an error, hopefully fixed in release 3. It should be alternative version used only when user has chosen to switch to it. It were not intended to replace bind package from CentOS/RHEL and it has to be fixed to not do that. Please check last version does not push itself into your system.pemensik edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by pemensik.
This update has been pushed to testing.
Not fixed. bind9-next-devel still provides bind-devel. That will cause dnf to pull in bind9-next-devel instead of bind-devel causing linking against wrong library.
I'd remove all these provides on epel.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Personally, I'm not sure how to reproduce @tis findings. For me bind9-next-9.19.9-3.el9 does no longer impact the bind packages from RHEL 9 (on a system having EPEL 9 stable and testing repositories enabled).
Actually testing got screwed. dnf testing pulled -2.el9 and package got upgraded before I had time to check.
This update can be pushed to stable now if the maintainer wishes
This package violates EPEL policy. Because bind-next-devel provides bind-devel, anything that build requires bind-devel will get built against this instead of the RHEL package.
@carlwgeorge Have you tried it with enabled (rhel-)CRB repository?
dnf builddep bind-dyndb-ldap.spec
installedbind-devel-9.16.23-7.el9.x86_64
to me. As did justdnf install bind-devel
. Can you provide detailed steps and list of enabled repositories you have tried? It should not replace bind-devel in current build.Here is the relevant section of EPEL policy:
Historically this has been interpreted to include both obsoleting and providing a RHEL package name. I believe this stems from yum behavior, where yum would pick an alternatively named package to satisfy a dependency if it provided the original name and had a higher version. If dnf has changed this behavior, we may need to revist the policy for EL8+.
Please file an issue for the EPEL Steering Commitee and we'll discuss this at the next meeting. Do not push this update to stable in the meantime.
Ah, I see the source of the confusion. The provides in this package do not include the epoch, so dependencies are still resolving to the RHEL package with the epoch.
As a separate test, I built three packages, foo-1-1.el9, bar-1-1.el9, and bar2-2-1.el9. foo requires bar, and bar2 provides bar. With those set up in a test repo,
dnf install foo
results in foo and bar2 being installed. dnf behavior hasn't changed.Please proceed with filing that issue so we can discuss it further to see if this should be allowed by policy.
Created https://pagure.io/epel/issue/221
I'm going to go ahead and pull this update, per https://pagure.io/epel/issue/221#comment-839699.
This update has been unpushed.