unpushed

bind9-next-9.19.9-3.el9

FEDORA-EPEL-2023-116ae883fe created by pemensik 2 years ago for Fedora EPEL 9
  • New package with development version of BIND9
  • Release notes
  • Hopefully avoids using bind9-next as a default package to satisfy various bind requires

This update has been submitted for testing by pemensik.

2 years ago

This update's test gating status has been changed to 'ignored'.

2 years ago

This update has been pushed to testing.

2 years ago

pemensik edited this update.

New build(s):

  • bind9-next-9.19.9-2.el9

Removed build(s):

  • bind9-next-9.19.9-1.el9

Karma has been reset.

2 years ago

This update has been submitted for testing by pemensik.

2 years ago

pemensik edited this update.

2 years ago

This update has been pushed to testing.

2 years ago
User Icon robert commented & provided feedback 2 years ago
karma

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.

2 years ago

pemensik edited this update.

2 years ago

pemensik edited this update.

2 years ago
User Icon pemensik commented & provided feedback 2 years ago

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.

pemensik edited this update.

New build(s):

  • bind9-next-9.19.9-3.el9

Removed build(s):

  • bind9-next-9.19.9-2.el9

Karma has been reset.

2 years ago

This update has been submitted for testing by pemensik.

2 years ago

This update has been pushed to testing.

2 years ago
User Icon tis commented & provided feedback 2 years ago
karma

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.

2 years ago
User Icon robert commented & provided feedback 2 years ago
karma

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).

User Icon tis commented & provided feedback 2 years ago
karma

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

2 years ago
User Icon carlwgeorge commented & provided feedback 2 years ago
karma

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.

User Icon pemensik commented & provided feedback 2 years ago

@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.

User Icon carlwgeorge commented & provided feedback 2 years ago

Here is the relevant section of EPEL policy:

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.

User Icon carlwgeorge commented & provided feedback 2 years ago

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.

User Icon pemensik commented & provided feedback 2 years ago
User Icon carlwgeorge commented & provided feedback 2 years ago

I'm going to go ahead and pull this update, per https://pagure.io/epel/issue/221#comment-839699.

This update has been unpushed.


Please login to add feedback.

Metadata
Type
newpackage
Severity
high
Karma
1
Signed
Content Type
RPM
Test Gating
Autopush Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Thresholds
Minimum Karma
+1
Minimum Testing
7 days
Dates
submitted
2 years ago
in testing
2 years ago
modified
2 years ago
BZ#2161942 Review Request: bind9-next - The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
0
0
BZ#2165256 Combined dependencies of bind, bind9-next, and freeipa-server mean system winds up with mix of bind and bind9-next, FreeIPA fails
0
0
BZ#2165264 what is the point of bind9-next in F36
0
0

Automated Test Results