DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides

[Sandro Mani]

On 12.06.2015 15:34, Orion Poplawski wrote:
> On 06/11/2015 10:01 AM, Sandro Mani wrote:
>> Hello,
>>
>> Investigating bug #1230838, I noticed that when installing mmg3d-libs,
>> dnf installs Konsole output ptscotch-mpich, whereas yum-deprecated
>> installs scotch. Both scotch and  ptscotch-mpich provide the required
>> libscotch.so.0()(64bit), albeit one in /usr/lib64/ and the other one in
>> /usr/lib64/mpich/lib/:
>>
>> $ dnf repoquery --requires mmg3d-libs
>> [...]
>> libscotch.so.0()(64bit)
>> libscotcherr.so.0()(64bit)
>> [...]
>>
>>
>> $ dnf provides 'libscotch.so.0()(64bit)'
>> ptscotch-mpich-6.0.4-2.fc23.x86_64 : PT-Scotch libraries compiled
>> against mpich
>> Repo        : rawhide
>>
>> ptscotch-openmpi-6.0.4-2.fc23.x86_64 : PT-Scotch libraries compiled
>> against openmpi
>> Repo        : rawhide
>>
>> scotch-6.0.4-2.fc23.x86_64 : Graph, mesh and hypergraph partitioning 
>> library
>> Repo        : rawhide
>>
>>
>> Konsole output $ dnf repoquery -l scotch.x86_64 | grep libscotch.so.0
>> /usr/lib64/libscotch.so.0
>> /usr/lib64/libscotch.so.0.2
>>
>>
>> Konsole output $ dnf repoquery -l ptscotch-mpich.x86_64 | grep
>> libscotch.so.0
>> /usr/lib64/mpich/lib/libscotch.so.0
>> /usr/lib64/mpich/lib/libscotch.so.0.2
>>
>>
>> $ dnf install mmg3d-libs
>> [...]
>> Installing:
>>   environment-modules                   x86_64
>> 3.2.10-14.fc23                    rawhide                   117 k
>>   hwloc-libs                            x86_64
>> 1.10.1-2.fc23                     rawhide                   1.3 M
>>   lzma-libs                             x86_64
>> 4.32.7-13.fc22                    rawhide                    38 k
>>   mmg3d-libs                            x86_64
>> 4.0.2-1.fc23                      rawhide                   211 k
>>   mpich                                 x86_64
>> 3.1.4-3.fc23                      rawhide                   1.1 M
>>   ptscotch-mpich
>>
>> $ yum-deprecated install mmg3d-libs
>> [...]
>> Installing:
>>   mmg3d-libs                     x86_64
>> 4.0.2-1.fc23                         rawhide 211 k
>> Installing for dependencies:
>>   lzma-libs                      x86_64
>> 4.32.7-13.fc22 rawhide                      38 k
>>   scotch
>>
>>
>> So, whose fault is this? Packaging of dnf? Nothing relevant for this
>> caught my eye skimming through the packaging guidelines.
>>
>> And related: trying to install some $pkg-openmpi package, I don't
>> generally see packages enforcing that the -openmpi version of some
>> dependency library is installed as opposed to just the regular libs
>> package. Should such requires need to be stated explicitly?
>
> MPI packages need to filter out the provides from the MPI versions and 
> explicitly add needed requires on the specific MPI flavors of packages 
> needed.  This probably needs to be added to the MPI guidelines.
>
Having had a go at this: if bar{-openmpi} requires foo-{openmpi}, 
filtering the provides from foo-openmpi and adding an explicit requires 
to bar-openmpi on foo-openmpi, this all will result in bar-openmpi 
depending both on foo-openmpi as well as foo. Obviously the requires 
could be filtered as well, but then things would start really getting 
cluttered with syntax overhead...

I was rather thinking, is there an obvious disadvantage in having a 
{mpich,openmpi}-find-requires.sh script which encodes the mpi flavour in 
the provides/requires? I.e.

libfoo.so.0()(64bit)(openmpi)

Rules to generate such requires/provides:
* Provides: if the path of the library starts with $MPI_LIB, append the 
(openmpi) resp (mpich) to the provides string
* Requires: if the path of the scanned object starts with $MPI_LIB and 
the required library exists in $MPI_LIB, add (openmpi) resp (mpich) to 
the requires string

Overriding the find-requires.sh could be done with a 
%{?openmpi_package_header}.

Thoughts?