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?