Description of problem:

  There are two versions of PSM libraries, PSM1 and PSM2.

  The PSM1 library was released as infinipath-psm, which only supports QLogic PSM hardware. The kernel driver of QLogic PSM hardware is "ib_qib.ko". First release of infinipath-psm is infinipath-psm-1.13.tar.gz, which was release in 2010.

  The PSM2 library only supports Intel hfi1 (OPA) hardware. In order to allow older applications linked against the library from infinipath-psm to be run on new clusters using hfi1 hardware, intel created a dynamic library "libpsm_infinipath.so.1" for PSM2. The libpsm2-compat package owns the "libpsm_infinipath.so.1" file of PSM2.

  As result, we have two packages provide two libraries in the same name. Two different libraries in one name introduces an race-condition issue for packages which built against PSM1. For example, openmpi built against infinipath_psm and libpsm2. In case you already have libpsm2-compat installed, yum/dnf will be failed to install openmpi.

  To resolve such regression issue for openmpi, infinipath-psm obsoletes libpsm2-compat. It looks strange as an older package obsoletes a newer package.

 Now, we seems have a better solution for this. This solution looks very strange too. The "libpsm_infinipath.so.1" file is the only library provides by libpsm2-compat. This library will be packaged up as a private library.


Version-Release number of selected component (if applicable):
libpsm2-compat-10.3.8-2.fc28.x86_64

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:
$ rpm -qpP libpsm2-compat-10.3.8-2.fc28.x86_64.rpm
libpsm2-compat = 10.3.8-2.fc28
libpsm2-compat(x86-64) = 10.3.8-2.fc28
libpsm_infinipath.so.1()(64bit)
libpsm_infinipath.so.1(PSM_1.0)(64bit)

Expected results:
$ rpm -qpP libpsm2-compat-10.3.8-2.fc28.x86_64.rpm
libpsm2-compat = 10.3.8-2.fc28
libpsm2-compat(x86-64) = 10.3.8-2.fc28

Additional info:

Will file another infinipath-psm to delete the obsolete between infipath-psm and libpsm2-compat.