The following ansible task used to work just fine, but fails with dnf5 5.2.13.1-1.fc41: - name: Test ansible.builtin.dnf: name: - 'https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-{{ ansible_distribution_major_version }}.noarch.rpm' - '@C Development Tools and Libraries' state: latest The following error is reported: libdnf5::OptionBool& libdnf5::ConfigMain::get_gpgcheck_option() is deprecated: Use get_pkg_gpgcheck_option() Traceback (most recent call last): File "/home/ansible/.ansible/tmp/ansible-tmp-1747065824.5896714-841923-191280431101143/AnsiballZ_dnf5.py", line 107, in <module> _ansiballz_main() ~~~~~~~~~~~~~~~^^ File "/home/ansible/.ansible/tmp/ansible-tmp-1747065824.5896714-841923-191280431101143/AnsiballZ_dnf5.py", line 99, in _ansiballz_main invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/ansible/.ansible/tmp/ansible-tmp-1747065824.5896714-841923-191280431101143/AnsiballZ_dnf5.py", line 47, in invoke_module runpy.run_module(mod_name='ansible.modules.dnf5', init_globals=dict(_module_fqn='ansible.modules.dnf5', _modlib_path=modlib_path), ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ run_name='__main__', alter_sys=True) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "<frozen runpy>", line 226, in run_module File "<frozen runpy>", line 98, in _run_module_code File "<frozen runpy>", line 88, in _run_code File "/tmp/ansible_ansible.legacy.dnf5_payload_mvidvohu/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py", line 768, in <module> File "/tmp/ansible_ansible.legacy.dnf5_payload_mvidvohu/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py", line 764, in main File "/tmp/ansible_ansible.legacy.dnf5_payload_mvidvohu/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py", line 659, in run File "/tmp/ansible_ansible.legacy.dnf5_payload_mvidvohu/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py", line 384, in is_newer_version_installed File "/usr/lib64/python3.13/site-packages/libdnf5/rpm.py", line 209, in parse return _rpm.Nevra_parse(*args) ~~~~~~~~~~~~~~~~^^^^^^^ libdnf5.exception.RpmNevraIncorrectInputError: Invalid character '/' in NEVRA string "https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-41.noarch.rpm" Very similar exception is reported when the group is the first item to be installed: libdnf5.exception.RpmNevraIncorrectInputError: Invalid character ' ' in NEVRA string "@C Development Tools and Libraries" I'm not sure how to reproduce the issue without ansible, but downgrading dnf5 packages from 5.2.13.1-1.fc41 to 5.2.6.2-1.fc41 fixes the issue. Reproducible: Always Steps to Reproduce: 1. # ansible-playbook --verbose test.yaml Actual Results: Fatal error reported for task "Test", see above Expected Results: No error
Created attachment 2089534 [details] test.yaml
I'm sorry, but this is not actionable for DNF5 team. If you have a problem with libdnf5 library, provide us a libdnf5 reproducer. DNF5 team have not idea how you invoke the library and what data you pass to it. You even did not wrote what ansible you use.
Yeah, sorry about it: ansible-9.13.0-1.fc41.noarch ansible-core-2.16.14-1.fc41.noarch
I was able to get the python code ansible is using for installing the packages. A pretty small working reproducer is: import libdnf5 base = libdnf5.base.Base() base.load_config() base.setup() libdnf5.rpm.Nevra.parse('@C Development Tools and Libraries') And the difference between working and broken state is the exception libdnf5 is raising in Nevra_parse. It used to be RuntimeError while the new version raises libdnf5.exception.RpmNevraIncorrectInputError. The ansible code only handles RuntimeError and thus it fails to install the packages with new libdnf5.
That said I guess this was an intentional change in libdnf5 and it's actually an issue in ansible that needs to adapt to this API change, right?
This is likely the result of this change: https://github.com/rpm-software-management/dnf5/pull/2118 We used to throw only RuntimeError exceptions and now we differentiate between multiple exception types, but I think they all inherit one of: libdnf5.exception.Error, libdnf5.exception.NonLibdnf5Exception, libdnf5.exception.UserAssertionError
Yes, it was an intentional change in Python (and other non-C++) bindings. It happened in 5.2.13.0 version and the motivation was to expose libdnf5 exceptions to the non C++ bindings. Before, all the exceptions Pavla named were translated to RuntimeError and Python application were unable distinguish a cause of the exceptions. This is now possible. It was handled as a fix for <https://github.com/rpm-software-management/dnf5/issues/291> because an intention was to have the same names of the exception types in C++ as well as in other languages. Those new exception types are not subtypes of RuntimeError. That's a breaking change. I'm sorry that nobody caught this API change. But now it's late. I can raise a question whether proper subtyping can be implemented in libdnf5, but my hopes are low. I recommend you adapting ansible to the new API. Actually the change is already known to Ansible <https://github.com/ansible/ansible/issues/84634>.
This has already been resolved in https://github.com/ansible/ansible/pull/84933 and included in the 2.18.5 release of ansible-core. I see reference to `2.16.14` which is only receiving security fixes at this time, and thus no fix will be made available to 2.16.
Oh, I did not find the ansible issue before filing this bug report. Let me move this to ansible then to make sure a working version is available in Fedora 41.
(In reply to Petr Pisar from comment #7) > Those new exception types are not subtypes of RuntimeError. That's a > breaking change. > > I'm sorry that nobody caught this API change. But now it's late. I can raise > a question whether proper subtyping can be implemented in libdnf5, but my > hopes are low. > DNF team discussed this API break: The exception type hierarchy was not preserved because the Swig code would be too obnoxious. For the very same reason, python3-dnf5 package won't remedy the break and it will keep the API as it is now. I recommend ansible-core RPM maintainer to apply the upstream fix <https://github.com/ansible/ansible/pull/84933> to ansible-core in all Fedora releases and add "Requires: python3-libdnf5 >= 5.2.13.0" dependency to the affected packages.
FEDORA-2025-19d54465b9 (ansible-core-2.16.14-2.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-19d54465b9
FEDORA-2025-19d54465b9 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-19d54465b9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-19d54465b9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-19d54465b9 (ansible-core-2.16.14-2.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.