Bug 1782899

I'm not sure what is going on with this.  A system exhibiting this problem will do the following without pulling in i686 packages:


# sudo dnf update libstoragemgmt
# sudo dnf update

If I exclude i686 to force a more meaningful error I get none.

#  sudo dnf groupinstall base -x \*i686

I think we are going to need someone more versed with dnf to take a look at this.  The system I was using is still in same state and will reproduce the issue.

Assigning to dnf for analysis.

Created attachment 1644569 [details]
output from dnf -v groupinstall base

Thanks for the report. From Comment 0 I can see that the issue is file conflict not in depsolving. The question is why i686 packages were pulled in or whe they have different version than x86_64? I also know that handling of i686 was improved in 8.1. Therefore please could you try to reproduce the issue once again but before any action please upgrade dnf, libdnf, libsolv to the latest version. Then did you experience different behaviour?

The issue is reproducible even with latest dnf, libdnf, libsolv-0.7.10.

There is a work around. Instead of `dnf groupinstall base` please could you try `dnf groupinstall base --nobest` and then `dnf group upgrade base`. Then i686 packages will not appears in transaction.


There is an issue in dnf or libsolv that handles the situation incorrectly. But I am unable to create a simple testcase for libsolv upstream with incorrect behaviour.

But there is another  problem in packaging of libstoragemgmt. python3-libstoragemgmt-clibs.x86-64 requires `libstoragemgmt = 1.8.1-2.el8`, but it should require `libstoragemgmt(x86-64) = 1.8.1-2.el8`. Following patch will resolve it.

diff --git a/libstoragemgmt.spec b/libstoragemgmt.spec
index 37dd22c..b15d35f 100644
--- a/libstoragemgmt.spec
+++ b/libstoragemgmt.spec
@@ -70,7 +70,7 @@ support and open source plug-ins written in python 3.
 %package        -n python3-%{name}-clibs
 Summary:        Python 3 C extension module for %{name}
 Group:          System Environment/Libraries
-Requires:       %{name} = %{version}-%{release}
+Requires:       %{name}%{?_isa} = %{version}-%{release}
 %{?python_provide:%python_provide python3-%{name}-clibs}
 
 %description    -n python3-%{name}-clibs

(In reply to Jaroslav Mracek from comment #9)
> There is a work around. Instead of `dnf groupinstall base` please could you
> try `dnf groupinstall base --nobest` and then `dnf group upgrade base`. Then
> i686 packages will not appears in transaction.
> 
> 

I confirm this workaround works for me!  Thank you!

I tried to create a libsolv reproducer but simplified case worked as expected.


repo @System 0 testtags <inline>
#>=Pkg: libstoragemgmt 1.0 1 x86_64
#>=Prq: python3-libstoragemgmt = 1.0-1
#>=Prv: libstoragemgmt = 1.0-1
#>=Pkg: python3-libstoragemgmt-clibs 1.0 1 x86_64
#>=Prq: libstoragemgmt = 1.0-1
#>=Prv: python3-libstoragemgmt-clibs = 1.0-1
#>=Pkg: python3-libstoragemgmt 1.0 1 noarch
#>=Prq: libstoragemgmt = 1.0-1
#>=Prv: python3-libstoragemgmt = 1.0-1

repo updates 0 testtags <inline>
#>=Pkg: libstoragemgmt 2.0 1 x86_64
#>=Prq: python3-libstoragemgmt = 2.0-1
#>=Prv: libstoragemgmt = 2.0-1
#>=Pkg: python3-libstoragemgmt-clibs 2.0 1 x86_64
#>=Prq: libstoragemgmt = 2.0-1
#>=Prv: python3-libstoragemgmt-clibs = 2.0-1
#>=Pkg: python3-libstoragemgmt 2.0 1 noarch
#>=Prq: libstoragemgmt = 2.0-1
#>=Prq: python3-libstoragemgmt-clibs
#>=Prv: python3-libstoragemgmt = 2.0-1
#>=Pkg: libstoragemgmt 2.0 1 i686
#>=Prq: python3-libstoragemgmt = 2.0-1
#>=Prv: libstoragemgmt = 2.0-1
#>=Pkg: python3-libstoragemgmt-clibs 2.0 1 i686
#>=Prq: libstoragemgmt = 2.0-1
#>=Prv: python3-libstoragemgmt-clibs = 2.0-1



system x86_64 rpm @System
poolflags implicitobsoleteusescolors

solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job install oneof libstoragemgmt-1.0-1.x86_64@@System libstoragemgmt-2.0-1.x86_64@updates libstoragemgmt-2.0-1.i686@updates [forcebest,targeted,setevr,setarch]
#job update all packages [forcebest]
#job update all packages
#job install oneof test-package-alpha-1.0-2.i386@updates [forcebest,targeted,setevr,setarch]
#job install oneof test-package-alpha-1.0-2.i386@updates [setevr,setarch]
result transaction,problems <inline>
#>upgrade libstoragemgmt-1.0-1.x86_64@@System libstoragemgmt-2.0-1.x86_64@updates
#>upgrade python3-libstoragemgmt-1.0-1.noarch@@System python3-libstoragemgmt-2.0-1.noarch@updates
#>upgrade python3-libstoragemgmt-clibs-1.0-1.x86_64@@System python3-libstoragemgmt-clibs-2.0-1.x86_64@updates

I've reported a bug against libsolv with a minimal test case reproducer of the problem:
https://github.com/openSUSE/libsolv/issues/383

I've also noticed python3-libstoragemgmt-1.8.3-1.el8 provides its name in two versions:

$ dnf repoquery --provides python3-libstoragemgmt-1.8.3-1.el8
python3-libstoragemgmt = 1.6.2-9.el8
python3-libstoragemgmt = 1.8.3-1.el8

This seems wrong and probably should be fixed. (it doesn't fix the i686 problem though)

The issue was fixed in upstream libsolv and should be a part of the 0.7.16 release.

I've created a test in our CI: https://github.com/rpm-software-management/ci-dnf-stack/pull/897

Changing the component to libsolv, as the fix was there:
https://github.com/openSUSE/libsolv/commit/894382f0c4ddf6d34b264544c3523a9094ec2a09

(slated for 0.7.16 release or higher)

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 (libsolv 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/RHBA-2021:1655