dnf whatprovides and library files

Radek Holy rholy at redhat.com
Thu Jun 11 09:03:17 UTC 2015



----- Original Message -----
> From: "Gordon Messmer" <gordon.messmer at gmail.com>
> To: "Community support for Fedora users" <users at lists.fedoraproject.org>
> Sent: Wednesday, June 10, 2015 7:38:13 PM
> Subject: Re: dnf whatprovides and library files
> 
> On 06/10/2015 12:24 AM, Ed Greshko wrote:
> > 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"
> 
> Interesting.  I've never actually seen an error with an installed shared
> object, so I never considered that you'd query one with "whatprovides."
> 
> In that case, I agree with you.  rpm and dnf behave differently with
> such a query (which I also did not know):
> 
> $ rpm -q  --whatprovides /lib64/libXv.so.1.*
> libXv-1.0.10-2.fc22.x86_64
> $ dnf whatprovides /lib64/libXv.so.1.*
> Error: No Matches found
> 
> dnf really should behave the same way as rpm.  If possible, it should
> call the rpm library functions for the query, rather than
> re-implementing them.
> 
> > Yes, rpm can tell you this *if* the file and providing package exists
> > on your system.  But, it is usual that you get a message about
> > something missing and that is where you need dnf.
> 
> Yes, but in the case where something is missing, you won't get a path.
> You'll get a shared object name, and querying that with "dnf
> whatprovides" will work correctly, as it is.

Anyone, feel free to file an RFE if you really need something mentioned in this thread.
-- 
Radek HolĂ˝
Associate Software Engineer
Software Management Team
Red Hat Czech


More information about the users mailing list