On 06/11/2015 02:03 AM, Radek Holy wrote:
Anyone, feel free to file an RFE if you really need something mentioned in this
thread.
https://bugzilla.redhat.com/show_bug.cgi?id=1230866
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin
- Original Message -
> From: "Gordon Messmer"
> To: "Community support for Fedora users"
> 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, j
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
On Wed, Jun 10, 2015 at 08:38:38PM +0900, Mamoru TASAKA wrote:
> >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 file
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 i
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
On 06/10/15 16:20, 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 c
- Original Message -
> From: "Ed Greshko"
> To: users@lists.fedoraproject.org
> Sent: Wednesday, June 10, 2015 9:24:09 AM
> Subject: Re: dnf whatprovides and library files
>
> On 06/10/15 14:55, Gordon Messmer wrote:
> > On 06/09/2015 04:53 PM, Ed G
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@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@f22k ~]# dnf what
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@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@f22k ~]# dnf whatprovides /lib64/libXv.so.1.0.0
That's the correct q
On Wed, Jun 10, 2015 at 11:24:09AM +0800, Ed Greshko wrote:
> > A 'usrmove provides' seems like a reasonable suggestion for a DNF
> > plugin — cover the normal symlinks in Fedora.
> I'm seriously considering reviving my script writing skills to put a wrapper
> around dnf to deal with /bin, /lib,
On 06/10/15 11:13, Matthew Miller wrote:
> A 'usrmove provides' seems like a reasonable suggestion for a DNF
> plugin — cover the normal symlinks in Fedora.
>
I'm seriously considering reviving my script writing skills to put a wrapper
around dnf to deal with /bin, /lib, /lib64, and /sbin. :-)
On Wed, Jun 10, 2015 at 10:12:58AM +0800, Ed Greshko wrote:
> While that does make sense it ends up being less than helpful for the
> average user to have to be aware of that. I dare say most end users
> don't care if a programmer has to jump through hoops to give a result
> which they feel "approp
On 06/10/15 09:35, Matthew Miller wrote:
> On Wed, Jun 10, 2015 at 09:26:36AM +0800, Ed Greshko wrote:
>> I wonder why they left it up to the user to determine symbolic links
>> are involved and not followed. Oh, well.
> It's because what's being searched is the database of files provided by
> a pa
On Wed, Jun 10, 2015 at 09:30:08AM +0800, Ed Greshko wrote:
> To make things even more confusing, in my mind, is that it isn't as
> simple as symbolic links.
> [egreshko@meimei /]$ ll /usr/lib64/libXv.so.1
> lrwxrwxrwx. 1 root root 14 Aug 17 2014 /usr/lib64/libXv.so.1 ->
> libXv.so.1.0.0
> [egres
On Wed, Jun 10, 2015 at 09:26:36AM +0800, Ed Greshko wrote:
> I wonder why they left it up to the user to determine symbolic links
> are involved and not followed. Oh, well.
It's because what's being searched is the database of files provided by
a package. The package doesn't actually provide the
On 06/10/15 09:26, Ed Greshko wrote:
> I wonder why they left it up to the user to determine symbolic links are
> involved and not followed. Oh, well.
To make things even more confusing, in my mind, is that it isn't as simple as
symbolic links.
[egreshko@meimei /]$ ll /usr/lib64/libXv.so.1
lrw
On 06/10/15 09:09, Matthew Miller wrote:
> On Wed, Jun 10, 2015 at 07:53:44AM +0800, Ed Greshko wrote:
>> For example, on an F22 system
>> [root@f22k ~]# ll /lib64/libXv.so.1.0.0
>> -rwxr-xr-x. 1 root root 19664 Aug 17 2014 /lib64/libXv.so.1.0.0
> $ file /lib64
> /lib64: symbolic link to `usr/
On Wed, Jun 10, 2015 at 07:53:44AM +0800, Ed Greshko wrote:
> For example, on an F22 system
> [root@f22k ~]# ll /lib64/libXv.so.1.0.0
> -rwxr-xr-x. 1 root root 19664 Aug 17 2014 /lib64/libXv.so.1.0.0
$ file /lib64
/lib64: symbolic link to `usr/lib64'
$ dnf whatprovides /usr/lib64/libXv.so.1
On 06/10/15 08:02, Joe Zeff wrote:
> On 06/09/2015 04:53 PM, Ed Greshko wrote:
>> What can I do to get "whatprovides" to work consistently?
>
> I know that yum is now deprecated, but does it still work for this? If so,
> there's a problem with dnf and you should file a bug report; if not dnf isn'
On 06/09/2015 04:53 PM, Ed Greshko wrote:
What can I do to get "whatprovides" to work consistently?
I know that yum is now deprecated, but does it still work for this? If
so, there's a problem with dnf and you should file a bug report; if not
dnf isn't part of the issue.
--
users mailing li
I can't seem to get dnf to tell me what package supplies a library.
For example, on an F22 system
[root@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@f22k ~]# dnf whatprovides /lib64/libXv.so.1.0.0
Last metadata expiration check perf
22 matches
Mail list logo
