The problem is 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`. The following patch for downstream spec 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

Hello,Tony

I reproduced this bug with RHEL-8.1 and libstoragemgmt 1.8.1-2.el8

log:
(119/120): libstoragemgmt-1.8.1-2.el8.x86_64.rpm                                                                                                                             2.8 MB/s | 266 kB     00:00    
(120/120): rhnsd-5.0.35-3.module+el8+2599+aa6b86f9.x86_64.rpm                                                                                                                 43 kB/s |  51 kB     00:01    
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                                        1.3 MB/s |  49 MB     00:38     
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
  file /usr/lib/tmpfiles.d/libstoragemgmt.conf conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64
  file /usr/share/doc/libstoragemgmt/NEWS conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64
  file /usr/share/man/man1/lsmcli.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64
  file /usr/share/man/man1/lsmd.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64
  file /usr/share/man/man1/simc_lsmplugin.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64
  file /usr/share/man/man5/lsmd.conf.5.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.1-2.el8.x86_64

Error Summary
-------------

[root@dell-per430-26 ~]# 


and also found with libstoragemgmt-1.8.3-1

log:
(114/115): libstoragemgmt-1.8.3-1.el8.x86_64.rpm                                                                                                                9.7 MB/s | 283 kB     00:00    
(115/115): rhnsd-5.0.35-3.module+el8+2599+aa6b86f9.x86_64.rpm                                                                                                    43 kB/s |  51 kB     00:01    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                           1.9 MB/s |  51 MB     00:26     
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  file /usr/lib/tmpfiles.d/libstoragemgmt.conf conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/doc/libstoragemgmt/NEWS conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/lsmcli.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/lsmd.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/simc_lsmplugin.1.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man5/lsmd.conf.5.gz conflicts between attempted installs of libstoragemgmt-1.6.2-9.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64

[root@hp-dl160g5-01 ~]# 





(113/114): libstoragemgmt-1.8.3-1.el8.x86_64.rpm                                                     36 MB/s | 283 kB     00:00    
(114/114): samba-client-libs-4.11.2-13.el8.x86_64.rpm                                                25 MB/s | 5.1 MB     00:00    
------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                20 MB/s |  51 MB     00:02     
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  file /usr/share/doc/libstoragemgmt/NEWS conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/lsmcli.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/lsmd.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/simc_lsmplugin.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man5/lsmd.conf.5.gz conflicts between attempted installs of libstoragemgmt-1.8.1-2.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64

[root@hp-dl160g5-01 ~]# 


this issue found with RHEL-8.1 (include 8.0repo and 8.1repo)  ,RHEL-8.2(include 8.0repo and 8.2repo,8.1repo and 8.2repo)
but when RHEL-8.1( only include 8.1repo) ,RHEL-8.2(only include 8.2repo) then 'dnf groupinstall base' can be executed successfully

please have a look and check if my reproduction step is wrong

Thanks

Created attachment 1665584 [details]
reproduced with RHEL-8.1

Created attachment 1665585 [details]
reproduced with RHEL-8.2

(In reply to Jaroslav Mracek from comment #1)
> The problem is 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`. The following
> patch for downstream spec 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

Jaroslav, I made the changes you suggested in this comment and 1 more as we have more than 1 python module with a clib, change I made is:

diff --git a/libstoragemgmt.spec b/libstoragemgmt.spec
index 37dd22c..74fdc20 100644
--- a/libstoragemgmt.spec
+++ b/libstoragemgmt.spec
@@ -2,7 +2,7 @@
 
 Name:           libstoragemgmt
 Version:        1.8.1
-Release:        3%{?dist}
+Release:        4%{?dist}
 Summary:        Storage array management library
 Group:          System Environment/Libraries
 License:        LGPLv2+
@@ -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
@@ -178,7 +178,7 @@ The nfs-plugin package contains plug-in for local NFS exports support.
 %package        nfs-plugin-clibs
 Summary:        Python C extension module for %{name} NFS plugin
 Group:          System Environment/Libraries
-Requires:       %{name} = %{version}-%{release}
+Requires:       %{name}%{?_isa} = %{version}-%{release}
 
 %description    nfs-plugin-clibs
 The %{name}-nfs-plugin-clibs package contains python C extension for %{name}
@@ -540,6 +540,9 @@ fi
 %{_mandir}/man1/local_lsmplugin.1*
 
 %changelog
+* Thu Feb 13 2020 Tony Asleson <tasleson> - 1.8.1-4
+- Fix dnf groupinstall base (RHBZ #1792370)
+
 * Wed Oct 30 2019 Tony Asleson <tasleson> - 1.8.1-3
 - Correct rpm -V (RHBZ #1726209)

which is included in 1.8.3-1.

Do I make a mistake in this change for the dependency generation to work or is this still part of the bug that needs to be addressed with Bug #1782899 ?

Thanks!

Hello Tony

Are there any new updates? do we have new version of lsm to fix this bug?

Thanks

(In reply to ChanghuiZhong from comment #8)
> Hello Tony
> 
> Are there any new updates? do we have new version of lsm to fix this bug?
> 
> Thanks

The issue is in NEEDINFO as I've believe I've done the requested spec file changes outlined in this issue and I'm waiting for a response.  Bug #1782899 is addressing an issue relating to this too, thus it's correction may be needed in conjunction with this but not sure.

It looks like a correct solution. The correct question would be whether the issue is still reproducible? No additional changes are required in DNF.
The original issue is still opened because we are looking for solution that will tolerate packaging issues on DNF side, but it looks like that it is impossible.

Please if I did not answered what you need, please don't hesitate to ask once again.

Hi,all

Thanks for the updated.
But from the test results, libstoragemgmt-1.8.3-1 still can reproduce this issue.
If it can be fixed, please re-publish new version, QE can verify again.

Thanks

The problem is in already release packages, but they cannot be removed from a distribution.

python3-libstoragemgmt-clibs-0:1.6.2-9.el8.x86_64
python3-libstoragemgmt-clibs-0:1.8.1-2.el8.x86_64

The issue will disappear after upgrade of python3-libstoragemgmt-clibs into the latest version. Than the issue will be not present any more.

I am sorry but I didn't touch anything. It was changed by reload. Nice feature of bugzilla.

I would like to propose a different test conditions. Install python3-libstoragemgmt-clibs-0:1.8.1-3.el8.x86_64 and other related component from that build then try to reproduce the issue with 'dnf groupinstall base'.

Hi,Jaroslav Mracek 

still can reproduce this issue with python3-libstoragemgmt-clibs-1.8.1-3.el8.x86_64

[root@dhcp-12-129 ~]# rpm -qa | grep libstoragemgmt
python3-libstoragemgmt-1.8.1-3.el8.noarch
libstoragemgmt-1.8.1-3.el8.x86_64
python3-libstoragemgmt-clibs-1.8.1-3.el8.x86_64
[root@dhcp-12-129 ~]# 

'dnf groupinstall base'

Total                                                                                618 kB/s |  74 MB     02:03     
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  file /usr/share/doc/libstoragemgmt/NEWS conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/lsmcli.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/lsmd.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man1/simc_lsmplugin.1.gz conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64
  file /usr/share/man/man5/lsmd.conf.5.gz conflicts between attempted installs of libstoragemgmt-1.8.1-3.el8.i686 and libstoragemgmt-1.8.3-1.el8.x86_64

[root@dhcp-12-129 ~]# 



This issue only occurs when the OS has two different versions of the repo.(eg:'rhel8.1 and rhel8.2' ,even different versions of rhel8.2 repo)

[beaker-BaseOS]
name=beaker-BaseOS
baseurl=http://download.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/RHEL-8.2.0-20191219.0/compose/BaseOS/x86_64/os
enabled=1
gpgcheck=0
skip_if_unavailable=1

[beaker-AppStream-8.2]
name=beaker-AppStream-8.2
baseurl=http://download-node-02.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/RHEL-8.2.0-20200310.0/compose/AppStream/x86_64/os/
enabled=1
gpgcheck=0

[beaker-BaseOS-8.2]
name=beaker-BaseOS-8.2
baseurl=http://download-node-02.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/RHEL-8.2.0-20200310.0/compose/BaseOS/x86_64/os/
enabled=1
gpgcheck=0





If only one repo exist, this issue will not occur.

[beaker-BaseOS-8.2]
name=beaker-BaseOS-8.2
baseurl=http://download-node-02.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/RHEL-8.2.0-20200310.0/compose/BaseOS/x86_64/os/
enabled=1
gpgcheck=0

Hello,Tony

https://errata.devel.redhat.com/advisory/47952 

since today is the deadline to push errata,if we are not sure or cannot verified,
https://bugzilla.redhat.com/show_bug.cgi?id=1741288
https://bugzilla.redhat.com/show_bug.cgi?id=1792370
we need remove this two bug from the errata

do you have any good idea and suggestion?

(In reply to ChanghuiZhong from comment #16)
> Hello,Tony
> 
> https://errata.devel.redhat.com/advisory/47952 
> 
> since today is the deadline to push errata,if we are not sure or cannot
> verified,
> https://bugzilla.redhat.com/show_bug.cgi?id=1741288
> https://bugzilla.redhat.com/show_bug.cgi?id=1792370
> we need remove this two bug from the errata
> 
> do you have any good idea and suggestion?

As Jaroslav mentioned, this bug for dnf groupinstall base fixes this issue but it will only help releases that come after this release, thus we cannot demonstrate that bug corrects this issue at this time.

(In reply to Tony Asleson from comment #17)
> (In reply to ChanghuiZhong from comment #16)
> > Hello,Tony
> > 
> > https://errata.devel.redhat.com/advisory/47952 
> > 
> > since today is the deadline to push errata,if we are not sure or cannot
> > verified,
> > https://bugzilla.redhat.com/show_bug.cgi?id=1741288
> > https://bugzilla.redhat.com/show_bug.cgi?id=1792370
> > we need remove this two bug from the errata
> > 
> > do you have any good idea and suggestion?
> 
> As Jaroslav mentioned, this bug for dnf groupinstall base fixes this issue
> but it will only help releases that come after this release, thus we cannot
> demonstrate that bug corrects this issue at this time.

so how do we deal with this bug?
can we move to "verified" first?
because this issue does not occur under normal situation, this issue only occurs if there are different repos in the OS.
and as you said this fix patch only help releases that come after this release.

(In reply to Tony Asleson from comment #17)
> (In reply to ChanghuiZhong from comment #16)
> > Hello,Tony
> > 
> > https://errata.devel.redhat.com/advisory/47952 
> > 
> > since today is the deadline to push errata,if we are not sure or cannot
> > verified,
> > https://bugzilla.redhat.com/show_bug.cgi?id=1741288
> > https://bugzilla.redhat.com/show_bug.cgi?id=1792370
> > we need remove this two bug from the errata
> > 
> > do you have any good idea and suggestion?
> 
> As Jaroslav mentioned, this bug for dnf groupinstall base fixes this issue
> but it will only help releases that come after this release, thus we cannot
> demonstrate that bug corrects this issue at this time.

so how do we deal with this bug?
can we move to "verified" first?
because this issue does not occur under normal situation, this issue only occurs if there are different repos in the OS.
and as you said this fix patch only help releases that come after this release.

(In reply to ChanghuiZhong from comment #19)
> so how do we deal with this bug?
> can we move to "verified" first?
> because this issue does not occur under normal situation, this issue only
> occurs if there are different repos in the OS.
> and as you said this fix patch only help releases that come after this
> release.

If we require positive confirmation that it's corrected before we release a fix for it we will never be able to post a fix for it, thus it will be perpetually broken.

In my opinion we should go forward with what we have as it's the only course of action to correct the problem.  Furthermore, there is a mitigation available that allows users to get past this issue if they run into it.

I believe our best course of action is to move forward with the issue.

Confirm that libstoragemgmt-1.8.6-1.el8 has fixed this issue.

[root@storageqe-24 ~]# rpm -qa | grep libstoragemgmt
python3-libstoragemgmt-clibs-1.6.2-9.el8.x86_64
libstoragemgmt-1.6.2-9.el8.x86_64
python3-libstoragemgmt-1.6.2-9.el8.noarch


[root@storageqe-24 ~]# dnf groupinstall base


[root@storageqe-24 ~]# rpm -qa | grep libstoragemgmt
python3-libstoragemgmt-1.8.6-1.el8.noarch
python3-libstoragemgmt-clibs-1.8.6-1.el8.x86_64
libstoragemgmt-1.8.6-1.el8.x86_64

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 (libstoragemgmt 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:1629