Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1847946
Summary: | libdnf behavior has changed unexpectedly in 8.3 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Jeff Needle <jneedle> |
Component: | libdnf | Assignee: | Pavla Kratochvilova <pkratoch> |
Status: | CLOSED ERRATA | QA Contact: | Radek Bíba <rbiba> |
Severity: | unspecified | Docs Contact: | Katerina Nemcova <knemcova> |
Priority: | high | ||
Version: | 8.3 | CC: | dlane, lmanasko, lmiksik, nsella, pkratoch, smaitra, vipatel, yguenane |
Target Milestone: | rc | Keywords: | Triaged |
Target Release: | 8.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libdnf-0.48.0-3.el8 | Doc Type: | No Doc Update |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-11-04 01:53:17 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: |
Description
Jeff Needle
2020-06-17 12:13:50 UTC
Yum repo file to use in order to reproduce [ansible-tower] name=Ansible Tower Repository - $releasever $basearch baseurl=https://releases.ansible.com/ansible-tower/rpm/epel-8-$basearch enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release [ansible-tower-dependencies] name=Ansible Tower Dependencies Repository - $releasever $basearch baseurl=https://releases.ansible.com/ansible-tower/rpm/dependencies/3.6/epel-8-$basearch enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release As a workaround, you can replace 'ansible-tower == 3.6.4' with 'ansible-tower = 3.6.4'. Btw, weird thing is, I can reproduce the bug (with different packages) on Fedora even with much older libdnf (libdnf-0.28.1-1.fc30.x86_64). I can confirm that changing == to = does work around this. I have nothing on why this is reproducible on older libdnf, but it's definitely a regression between 8.2 and 8.3. I just found out that the '==' operator is not valid when defining dependencies in spec file (see the rpm documentation at https://rpm.org/user_doc/dependencies.html or in /usr/share/doc/rpm/dependencies) and the fact that libdnf accepted it was actually a temporary mistake. Is it possible to replace the '==' with '=' in all the cases at your end? > Is it possible to replace the '==' with '=' in all the cases at your end?
For future Ansible Tower releases, yes. The problem is for the releases that are currently out there it will be impossible to install them on 8.3 onward until a maintenance release is released.
From a user perspective, it would simply be broken/regression.
As much as I understand this was a temporary mistake, Would it be possible to re-enable it for 8.y time frame to no provide non-backward compatible change ? Then, once we start testing RHEL 9.y we would be find removing it.
(In reply to Yanis Guenane from comment #5) > > Is it possible to replace the '==' with '=' in all the cases at your end? > > For future Ansible Tower releases, yes. The problem is for the releases that > are currently out there it will be impossible to install them on 8.3 onward > until a maintenance release is released. > From a user perspective, it would simply be broken/regression. Would it be possible to fix this in the Ansible Tower maintenance release (by changing '==' to '=')? If it's not possible, could you provide more details on Ansible Tower schedule - when a new release is planned? > As much as I understand this was a temporary mistake, Would it be possible > to re-enable it for 8.y time frame to no provide non-backward compatible > change ? Then, once we start testing RHEL 9.y we would be find removing it. The problem is, bringing back the '==' support in dnf would mean inconsistency with other tools, such as rpm, and what is more important, the behavior is undefined and we cannot guarantee it's correct. For that reason, we are a bit reluctant to bring it back to RHEL 8. If there's no other way, we can bring it back, but we'll emit a warning about using an unsupported behavior that will be dropped in RHEL 9 and Fedora. This behaviour introduces a regression in our installation procedure in all currently supported versions (3.4.z, 3.5.z, 3.6.z and 3.7.z).
Because of this regression we would need to re-release all currently supported versions of Tower to work around this regression.
While we can update our installation procedure for this not to happen in the future, we would still want the old behaviour to still be available for RHEL8 for the time being.
> If there's no other way, we can bring it back, but we'll emit a warning about using an unsupported behavior that will be dropped in RHEL 9 and Fedora.
This is def. fine with us.
I made a patch that brings back the '==' support with deprecation warning: https://github.com/rpm-software-management/libdnf/pull/985 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (yum bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:4510 |