Dependency generator hooks and extending default requires/provides

Sandro Mani manisandro at gmail.com
Sat Jul 4 23:04:06 UTC 2015



On 02.07.2015 09:00, Thierry Vignaud wrote:
> Just tell in mpo.attr what files are of interest for you and write a
> script that compute the additional deps that are missing by rpmdeps
> with default attr files
> You've to write a script that will actually output the
> "libfoo.so()(64bit)(mpich-x86_64)" requires/provides you want.
> You must _NOT_ call rpmdeps.
> Rpmdeps is just the high level program that collects the deps computed
> by the various *.prov/*.req scripts according to *.attr rules.
>
> So according to your links,
> mpi.prov should do sg like
>
> "if the path of the library starts with $MPI_LIB, append the
> (openmpi) resp (mpich) to the provides string"
>
> mpi.req should do sg like:
> "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"
Ok, by simply calling elfdeps (whose existence I hadn't noticed 
previously) I solved the endless loop issue and the scripts [1] now 
behave as desired.
>
> You'll still got the generic "libfoo.so()(64bit)" provides but as
> you'll provides & requires additional tags.
This is the last hurdle I'm facing: an elf binary in an $MPI_HOME 
subfolder will now trigger both the elf as well as the mpi dependency 
generator, resulting in i.e. both

libfoo.so()(64bit)
libfoo.so()(64bit)(openmpi-x86_64)

being generated for /usr/lib64/openmpi/lib/libfoo.so. For the problem I'm trying to solve [*], my goal is to only have libfoo.so()(64bit)(openmpi-x86_64). The only solution which comes to mind is adding

%__elf_exclude_path     ^%{_prefix}/lib(64)/(openmpi|mpich)/.*$

to elf.attr. This is somewhat hacky, but is there a cleaner approach?

Thanks,
SandroKonsole output  Konsole output

[1] https://smani.fedorapeople.org/rpm-mpi-hooks/ [*] Namely that if 
both libfoo and libfoo-openmpi provide libfoo.so, DNF can end up 
installing libfoo-openmpi for a non-mpi package bar which has a requires 
on libfoo (whereas YUM used to pick the providing package with the 
shorter name - the change in behavior in DNF is the reason this is 
suddenly a "problem").
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20150705/de504b6e/attachment.html>


More information about the Rpm-list mailing list