F36 is in the middle of a stable release what's the point of "bind9-next" at all? why is it thrown to F36/F37 at that point? why does it obsolete current bind-packages? [root@srv-rhsoft:~]$ dnf upgrade Last metadata expiration check: 0:03:24 ago on Sun Jan 29 00:59:11 2023. Dependencies resolved. Problem 1: package bind-chroot-32:9.16.33-1.fc36.x86_64 requires bind(x86-64) = 32:9.16.33-1.fc36, but none of the providers can be installed - package bind9-next-32:9.19.9-1.fc36.x86_64 conflicts with bind provided by bind-32:9.16.33-1.fc36.x86_64 - package bind9-next-32:9.19.9-1.fc36.x86_64 obsoletes bind < 32:9.17.0 provided by bind-32:9.16.33-1.fc36.x86_64 - cannot install the best update candidate for package bind-chroot-32:9.16.33-1.fc36.x86_64 - cannot install the best update candidate for package bind-32:9.16.33-1.fc36.x86_64 Problem 2: package lounge-rhsoft-workstation-36.0-3.fc36.20230110.rh.noarch requires bind-utils, but none of the providers can be installed - package bind9-next-utils-32:9.19.9-1.fc36.x86_64 conflicts with bind-utils provided by bind-utils-32:9.16.33-1.fc36.x86_64 - package bind9-next-utils-32:9.19.9-1.fc36.x86_64 obsoletes bind-utils < 32:9.17.0 provided by bind-utils-32:9.16.33-1.fc36.x86_64 - package bind9-next-utils-32:9.19.9-1.fc36.x86_64 conflicts with bind-utils provided by bind-utils-32:9.16.27-1.fc36.x86_64 - package bind9-next-utils-32:9.19.9-1.fc36.x86_64 obsoletes bind-utils < 32:9.17.0 provided by bind-utils-32:9.16.27-1.fc36.x86_64 - cannot install the best update candidate for package lounge-rhsoft-workstation-36.0-3.fc36.20230110.rh.noarch - cannot install the best update candidate for package bind-utils-32:9.16.33-1.fc36.x86_64 ================================================================================================================================================================================== Package Architecture Version Repository Size ================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): bind-utils x86_64 32:9.16.27-1.fc36 fedora 203 k bind9-next x86_64 32:9.19.9-1.fc36 updates-testing 520 k bind9-next-utils x86_64 32:9.19.9-1.fc36 updates-testing 221 k Transaction Summary ================================================================================================================================================================================== Skip 3 Packages Nothing to do. Complete!
Oh, this is related to bug #2165256, which fix will correct also this problem. It was never meant to conflict during normal update or even replace bind package in a normal update. It was supposed to be just alternative installed only when requested explicitly. I put Obsoletes: bind just to allow simple dnf install bind9-next. I made sure it were not active for f37+, but I forgot it may have unexpected consequences. I am sorry for this conflict, I will try to resolve it soon properly. Perhaps the obsolete is not wanted in any situation and it would be better to rely on dnf swap instead. Ie. dnf install bind9-next with bind installed would fail. But this would work instead: dnf swap bind bind9-next
bind9-next has incompatible configuration with bind. E.g. dnssec-enable option triggers a fatal error in bind9-next. Please remove the obsoletes from bind9-next* packages: # rpm -q bind9-next --obsoletes bind < 32:9.17.0 bind9-next-pkcs11 < 32:9.18.4-2
dnssec-enable option does not work in any supported Fedora versions. It does not work even in epel9 build. Last version where it actually does something is 9.11.x, which is still in RHEL8 and RHEL7. But I have not made such builds of bind9-next. It will fail even with bind package on f37 and later. I admit bind obsolete were not the best idea, but I think dnssec-enable option is not necessary in any supported configurations. dnssec-validation is the one you may want instead. Is there a specific reason why do you have it in your configuration, Petr?
for my part we have "dnssec-enable no;" and "dnssec-validation no;" in our configuration because years ago some moron of a maintainer/developer thought it's a good idea to mangle around in the existing configuration (which is general do-not-touach-area oustide of .rpmnewfiles), enabled it (including a synatx error) and broke our complete external name resolution (because that crap did'nt work even when enabled with the correct syntax): https://bugzilla.redhat.com/show_bug.cgi?id=510290#c2
dnssec-enable no; breaks any software attempting to do dnssec validation for all names. I would discourage it even on any instance where it actually does something. That is not true on any supported Fedora releases. If you insist you do not want validation, then okay, use dnssec-validation no;. dnssec-enabled no; is not needed by any non-broken software I know. It just breaks more things. Please if you used it in history, reconsider that now. That is true any version from RHEL 7 higher. If you know a situation where dnssec-enabled no; is indeed required, I would like to know that case. The only good thing is pretending it does not know how to handle DNSSEC records. Any software requiring that should be fixed instead. I do not know any such package in RHEL or Fedora. Do you? Anyway, it seems removing Obsoletes: bind helps.
as said: don't touch a working system and set both options to no which weren't present before some clown touched the config fixed name resolution in 2009 and works until today pretty fine fro 14 years and for "removing Obsoletes: bind helps": how did you ever come to the idea "Obsoletes: bind" could do anything useful and how comes that you didn't test that simply by throwing the packages into a local repo and run "dnf upgrade" before even come to the idea touching F36? and yes since 2009 i sound harsh when someone is touching named without cafeful testing what he is doing
FEDORA-2023-803a3b98c4 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-803a3b98c4
FEDORA-2023-76a93ef3d2 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-76a93ef3d2
FEDORA-EPEL-2023-116ae883fe has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-116ae883fe
Hopefully fixed in rawhide.
(In reply to Petr Menšík from comment #3) > dnssec-enable option does not work in any supported Fedora versions. It does > not work even in epel9 build. Last version where it actually does something > is 9.11.x, which is still in RHEL8 and RHEL7. But I have not made such > builds of bind9-next. It will fail even with bind package on f37 and later. > > I admit bind obsolete were not the best idea, but I think dnssec-enable > option is not necessary in any supported configurations. dnssec-validation > is the one you may want instead. Is there a specific reason why do you have > it in your configuration, Petr? Many years ago I added "dnssec-enable yes;" because, I think, at that time DNSSec was disabled by default. I just did not notice that the option is void now. I wrote it down here as an example where the two binds are incompatible and that it's a bug to replace them in stable Fedoras.
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.
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.