Bug 2120356
| Summary: | dnf check-update says that gimp-libs.i686 obsoletes gimp-libs.x86_64 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Andrew Schorr <ajschorr> |
| Component: | gimp | Assignee: | Josef Ridky <jridky> |
| Status: | CLOSED MIGRATED | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | CentOS Stream | CC: | bstinson, james.antill, jwboyer, ovasik, ppisar |
| Target Milestone: | rc | Keywords: | MigratedToJIRA, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-09-21 22:08: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: | |||
RHEL 9 does not have a modular gimp. This Obsoletes was inherited from Fedora 30 (bug #1772469). The easiest fix is removing the Obsoletes from gimp package in RHEL 9. Also the Obsolete version constrain (< %{epoch}:%{version}-%{release}) is not safe. It should hard-code the version that was latest in the module (e.g. < 2.1-2). This way you obsolete all previous releases including the already installed gimp. This triggers replacing the installed package and an attempt to use a different architecture. > Should the Obsoletes specify the ISA to avoid this issue? Or is "dnf check-update" being stupid?
Indeed "dnf check-update" displays a different output from "dnf upgrade", though at the end it reports the same two packages for update as "dnf upgrade":
# dnf check-update
Last metadata expiration check: 0:05:28 ago on Tue 30 Aug 2022 11:23:02 AM CEST.
gimp.x86_64 2:2.99.8-3.el9 rhel-9.1.0-appstream
gimp-libs.x86_64 2:2.99.8-3.el9 rhel-9.1.0-appstream
Obsoleting Packages
gimp.x86_64 2:2.99.8-3.el9 rhel-9.1.0-appstream
gimp.x86_64 2:2.99.8-2.el9_0.1 @pulp-appstream
gimp-libs.i686 2:2.99.8-3.el9 rhel-9.1.0-appstream
gimp-libs.x86_64 2:2.99.8-2.el9_0.1 @pulp-appstream
gimp-libs.x86_64 2:2.99.8-3.el9 rhel-9.1.0-appstream
gimp-libs.x86_64 2:2.99.8-2.el9_0.1 @pulp-appstream
# dnf upgrade
Last metadata expiration check: 0:05:40 ago on Tue 30 Aug 2022 11:23:02 AM CEST.
Dependencies resolved.
==================================================================================================================================================================================================================
Package Architecture Version Repository Size
==================================================================================================================================================================================================================
Upgrading:
gimp x86_64 2:2.99.8-3.el9 rhel-9.1.0-appstream 19 M
gimp-libs x86_64 2:2.99.8-3.el9 rhel-9.1.0-appstream 559 k
Transaction Summary
==================================================================================================================================================================================================================
Upgrade 2 Packages
Total download size: 20 M
Is this ok [y/N]: N
Operation aborted.
It think this is just a more verbose DNF message which does not cause any harm.
It actually does cause some harm for me, because I use the output of "dnf check-update" to download potential package updates for subsequent review. In this case, it caused my rpm update caching system to download gimp-libs.i686 and all of its dependencies. What's the benefit of not fixing the rpm spec file to avoid this? I've been forced to hardcode an exception to ignore this spurious output from "dnf check-update". Regards, Andy Check-update is only an approximate resolution. dnf(8) reads:
Please note that having a specific newer version available for an installed package (and
reported by check-update) does not imply that subsequent dnf upgrade will install it. The
difference is that dnf upgrade has restrictions (like package dependencies being satis‐
fied) to take into account.
I recommend "dnf upgrade --downloadonly" for your use case. Or "dnf upgrade --assumeno" if you only want the package list.
Thanks. I actually use the obsoleting packages info in the check-update output as part of my process, but I will try using "dnf --assumeyes --downloadonly --downloaddir=<download directory> update" to grab the files instead of downloading them individually. Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |
Description of problem: When I run "dnf check-update", the output claims that gimp-libs.i686 obsoletes gimp-libs.x86_64. I do not have any *.i686 rpms installed on this system. Version-Release number of selected component (if applicable): dnf-4.12.0-2.el9.noarch How reproducible: always Steps to Reproduce: 1. dnf check-update 2. 3. Actual results: gimp.x86_64 2:2.99.8-3.el9 appstream gimp-libs.x86_64 2:2.99.8-3.el9 appstream ... Obsoleting Packages gimp.x86_64 2:2.99.8-3.el9 appstream gimp.x86_64 2:2.99.8-2.el9 @System gimp-libs.i686 2:2.99.8-3.el9 appstream gimp-libs.x86_64 2:2.99.8-2.el9 @System gimp-libs.x86_64 2:2.99.8-3.el9 appstream gimp-libs.x86_64 2:2.99.8-2.el9 @System Expected results: I do not expect to see gimp-libs.i686 obsoleting gimp-libs.x86_64 in the results. Additional info: Running "dnf update" does not attempt to install gimp-libs.i686. I don't know whether this is a dnf issue, or a packaging problem with the gimp spec file. The gimp spec file says: #Demodularizing of gimp (#1772469) Obsoletes: %{name}-libs < %{epoch}:%{version}-%{release} Conflicts: %{name}-libs < %{epoch}:%{version}-%{release} Should the Obsoletes specify the ISA to avoid this issue? Or is "dnf check-update" being stupid?