[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
From: Sandro Mani <manisandro () gmail ! com>
Date: 2015-06-14 14:28:33
Message-ID: 557D8F91.1010109 () gmail ! com
[Download RAW message or body]
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic