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?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
