Bug 2165256
Summary: | Combined dependencies of bind, bind9-next, and freeipa-server mean system winds up with mix of bind and bind9-next, FreeIPA fails | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | bind9-next | Assignee: | Petr Menšík <pemensik> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 38 | CC: | dns-sig, mhroncok, pemensik, pspacek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | bind9-next-9.19.9-2.fc38 bind9-next-9.19.9-3.fc37 bind9-next-9.19.9-3.fc36 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-02-08 01:02:04 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 2165264 |
Description
Adam Williamson
2023-01-28 22:48:58 UTC
Making bind-dyndb-ldap conflict with bind9-next seems to help here: https://openqa.stg.fedoraproject.org/tests/2542883 that's a test of a bind-dyndb-ldap build with the conflict added, it passed, and the logs show no bind9-next installed. bind9-next-dnssec-utils does still get installed and pull in bind9-next-libs - I guess for the same reason, it provides 'bind-dnssec-utils' with a higher version than the one from bind - but fortunately that doesn't seem to break anything. I don't know if this is the best fix, but it at least works and seems pretty safe for now, so I'll do an official build with that change to keep Rawhide working over the weekend. I'll test and see if the bind-9.18.11 update works OK with that change too. sorry for the dumbly named build, I made it bind-dyndb-ldap-11.10-11.2.fc38 when it should've been bind-dyndb-ldap-11.10-12.fc38. d'oh. won't hurt anything, though. With that build things seem OK, but I'm going to leave this bug open for Petr to think what the best approach would be overall to avoid this kind of mixup or 'getting the wrong thing'. Does bind9-next really need to provide the exact package names of the bind packages? See bz2165295. nothing provides libdns-9.18.10.so()(64bit) needed by bind-dyndb-ldap-11.10-11.2.fc38.x86_64 gah, that'll be because I did the bind-dyndb-ldap build with the Conflicts: against bind 9.18.10, as bind 9.18.11 was untagged at the time, then we retagged 9.18.11 after fixing this...one more rebuild of bind-dyndb-ldap should get it. Nothing provides libdns-9.18.10.so, because I made update at friday to libdns-9.18.11. I think that means bind9-next-libs should have conflicts with bind-dyndb-ldap. But I admit this result is unexpected. I relied on prefference of dnf, but it seems it prefers bind-utils over bind9-next-utils only when it is specified on command line. If it is dragged by any dependency, it prefers bind9-next-utils since it is available in repositories. I think I will have to remove Provides: bind-utils and Provides: bind from the bind9-next (sub)packages. I want it to be working alternative, not preferred upgrade path. It seems my checks did not take nested depedencies into account. FEDORA-EPEL-2023-116ae883fe has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-116ae883fe FEDORA-2023-76a93ef3d2 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-76a93ef3d2 FEDORA-2023-803a3b98c4 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-803a3b98c4 I have removed %{epoch}: from Provides:. This way this package still provides the dependency, but does not have higher version than bind package anymore. That should make manual installations to work, but with default bind or bind-utils installed by default. Because they have the highest version when including epoch in their own version. That should do the trick also for other packages depending on bind-utils. Build on rawhide. FEDORA-EPEL-2023-116ae883fe has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-116ae883fe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-76a93ef3d2 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-76a93ef3d2 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-76a93ef3d2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-803a3b98c4 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-803a3b98c4 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-803a3b98c4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. "Nothing provides libdns-9.18.10.so, because I made update at friday to libdns-9.18.11." That was my fault, sorry - what happened is first we untagged the bind update as I thought it was the cause of the problem, then I noticed the bind9-next mess, so I did a build of bind-dyndb-ldap with Conflicts: bind9-next . That solved the problem, but because bind 9.8.11 was untagged at the time, that build was against 9.8.10...then we re-tagged 9.8.11 :P So I had to rebuild bind-dyndb-ldap one more time against 9.8.11. All should be in line now. Thanks for the change to bind9-next, I think the Conflicts: in bind-dyndb-ldap is still probably a good idea though. It makes sense for it to conflict with whichever bind package it *wasn't* built against, I think. FEDORA-EPEL-2023-116ae883fe has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-116ae883fe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-803a3b98c4 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-803a3b98c4 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-803a3b98c4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-76a93ef3d2 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-76a93ef3d2 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-76a93ef3d2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38. FEDORA-2023-803a3b98c4 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2023-76a93ef3d2 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |