dnf whatprovides and library files

Ed Greshko ed.greshko at greshko.com
Wed Jun 10 07:24:09 UTC 2015


On 06/10/15 14:55, Gordon Messmer wrote:
> On 06/09/2015 04:53 PM, Ed Greshko wrote:
>> I can't seem to get dnf to tell me what package supplies a library.
> ...
>> [root at f22k ~]# ll /lib64/libXv.so.1.0.0
>> -rwxr-xr-x. 1 root root 19664 Aug 17  2014 /lib64/libXv.so.1.0.0
>> [root at f22k ~]# dnf whatprovides /lib64/libXv.so.1.0.0
>
> That's the correct query for a file, but not a library.
>
> Two things:
>
> First, applications don't link against libXv.so.1.0.0, they link against libXv.so.1.  It is up to the dynamic linker to locate that library within the search path:
>
> $ ldd /usr/bin/xvinfo | grep libXv
>     libXv.so.1 => /lib64/libXv.so.1 (0x00000032d3600000)
>
> You'll see the same string in the first column when a library is not found, so that's the string that you look for.
>
> Second, rpm generates "provides" with pathless library names.  In the example above, "xvinfo" is linked against "libXv.so.1".  rpm behaves the same way.  Since the application is linked against "libXv.so.1" that is the correct string to use when searching for a package that provides it.
>
> $ dnf whatprovides libXv.so.1
> libXv-1.0.10-2.fc22.i686 : X.Org X11 libXv runtime library
> Repo        : @System
>

Thanks for the info....

But, just to be clear, the issue I'm addressing is what an average user may do in a given circumstance.  Upon seeing an error message such as this one,

error while loading shared libraries: /lib64/libexempi.so.3: file too short

assuming they know of dnf whatprovides I think it is more likely they will simply use copy/paste and issue the command "dnf whatprovides /lib64/libexempi.so.3"

Yes, the Subject I picked was not as accurate as it would be had I known then what I know now.  Maybe....  :-)

-- 
Sorta what I want to say when folks habitually complain about Fedora - https://youtu.be/ZArl8fTfub4



More information about the users mailing list