dnf whatprovides and library files

[Mamoru TASAKA]

Matthew Miller wrote on 06/10/2015 08:11 PM:
> On Wed, Jun 10, 2015 at 04:20:13AM -0400, Radek Holy wrote:
>> BTW, RPM can do that:
>> $ rpm --query --file /lib64/libXv.so.1.0.0
>> So, if RPM tracks these symlinks and if it provides an API to get this information, DNF could do the magic at least for the installed packages. But maybe it could become even more confusing for users since "whatprovides" would sometimes find the package and sometimes not depending on whether the package is installed or not. Maybe printing a warning would be sufficient...
>
> I believe RPM isn't tracking the symlink — it's just canonicalizing the
> filename when you do the --query --file (or -qf). Easy to do _on_ the
> system, not so good when you're asking about a non-existent file.

On installed files rpm -qf checks the "fingerprint" of the file
and compares with all rpmdb entries having the same basename
https://lists.fedoraproject.org/pipermail/devel/2012-February/161994.html

Mamoru

> An approach a DNF plugin might take, though, would be to look at all
> existing elements of the pathname and see if they can be canonicalized.
> And it looks like python's `os.path.realpath()` actually works that
> way, so you could just try calling that on any filenames passed to dnf
> provides. However, I bet we are inconsistent and have some places on
> the system where files are installed into a location under a symlink,
> by _that_ name. So, perhaps best to just special-case the usrmove paths
> /bin, /sbin, /lib, and /lib64.
>