If I run something like, "dnf -y install xxxx", and xxxx is already installed, DNF gives a response like the following.
Last metadata expiration check performed 0:00:02 ago on ... Package xxxx is already installed, skipping. ... (long delay, sometimes several minutes) ... Dependencies resolved. Nothing to do. Complete!
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
On Tue, Mar 29, 2016 at 10:36:37AM -0700, CLOSE Dave wrote:
If I run something like, "dnf -y install xxxx", and xxxx is already installed, DNF gives a response like the following. Last metadata expiration check performed 0:00:02 ago on ... Package xxxx is already installed, skipping. ... (long delay, sometimes several minutes) ... Dependencies resolved. Nothing to do. Complete!
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
I can't replicate this:
$ time sudo dnf install firefox Last metadata expiration check: 2:03:34 ago on Tue Mar 29 12:59:50 2016. Package firefox-45.0.1-2.fc23.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete!
real 0m1.362s user 0m1.197s sys 0m0.099s
I can't either:
[markh@aurelian ~]$ time sudo dnf install firefox Last metadata expiration check: 1:27:25 ago on Tue Mar 29 13:44:11 2016. Package firefox-45.0.1-2.fc23.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete!
real 0m2.087s user 0m1.914s sys 0m0.125s
Maybe a 'dnf clean all' might help with that.
On Tue, Mar 29, 2016 at 3:04 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Mar 29, 2016 at 10:36:37AM -0700, CLOSE Dave wrote:
If I run something like, "dnf -y install xxxx", and xxxx is already installed, DNF gives a response like the following. Last metadata expiration check performed 0:00:02 ago on ... Package xxxx is already installed, skipping. ... (long delay, sometimes several minutes) ... Dependencies resolved. Nothing to do. Complete!
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
I can't replicate this:
$ time sudo dnf install firefox Last metadata expiration check: 2:03:34 ago on Tue Mar 29 12:59:50 2016. Package firefox-45.0.1-2.fc23.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete!
real 0m1.362s user 0m1.197s sys 0m0.099s
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Tue, Mar 29, 2016 at 12:16:00PM -0700, Joe Zeff wrote:
On 03/29/2016 12:04 PM, Matthew Miller wrote:
I can't replicate this:
Neither can I, and the metadata is 3 days, 14:22:13 hours old. Possibly dnf has been configured to get new metadata every time, because it looks like it was last refreshed 2 seconds ago.
I don't think that's it either, because in that case the slow part will be at the beginning, before the depsolving even.
Several folks have responded that they don't see the same behavior I do. I don't doubt that. Even for me, the behavior is erratic, sometimes very slow, sometimes not.
The specific instance which prompted my note was an attempt to install from a local RPM file, not even from a repository. The machine in question is configured so that most repositories, and all non-local repos, are disabled by default anyway. The dnf.conf file says (just the default),
[main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True
From: "CLOSE Dave" Dave.Close@us.thalesgroup.com
Several folks have responded that they don't see the same behavior I do. I don't doubt that. Even for me, the behavior is erratic, sometimes very slow, sometimes not.
The resolution is fast, it can delay because of some expensive plugin hook call.
Can you try this: "dnf install <pkg> --disableplugin=*"
If you find a general reproducer, please report it [1] with these outputs attached: # rpm -q libsolv dnf hawkey # dnf repoquery --installed dnf-plugin*
Thanks, Honza
[1] https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting
On 03/29/2016 12:04 PM, Matthew Miller wrote:
On Tue, Mar 29, 2016 at 10:36:37AM -0700, CLOSE Dave wrote:
If I run something like, "dnf -y install xxxx", and xxxx is already installed, DNF gives a response like the following. Last metadata expiration check performed 0:00:02 ago on ... Package xxxx is already installed, skipping. ... (long delay, sometimes several minutes) ... Dependencies resolved. Nothing to do. Complete!
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
I can't replicate this:
$ time sudo dnf install firefox Last metadata expiration check: 2:03:34 ago on Tue Mar 29 12:59:50 2016. Package firefox-45.0.1-2.fc23.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete!
real 0m1.362s user 0m1.197s sys 0m0.099s
I've seen this. If this is an upgraded machine (I mean like from F21->F22->F23 or something), then rpm (and hence dnf) actually takes a while to plow through all the entries in its database to make sure everything's up to snuff. If it's a fairly new machine (very few upgrades) then it's fast.
My machine at home has been upgraded (with MANY a fight!) from F18 up through F23, so rpm takes a LONG time. For example, try something like
rpm -qa | grep ssh
Time that on a new, fresh install and on one that's been upgraded several times. You'll see what I mean. I've tried to purge rpm's database to speed it up:
rm -f /var/lib/rpm/__db* rpm --rebuilddb"
but it's never seemed to help. I guess there's enough crumbs left in the various /var/lib/rpm directories for it to pretty much put everything back in there and frankly, it doesn't bother me that much. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Denial. It ain't just a river in Egypt anymore! - ----------------------------------------------------------------------
On Tue, 29 Mar 2016 10:36:37 -0700 CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
If I run something like, "dnf -y install xxxx", and xxxx is already installed, DNF gives a response like the following.
Last metadata expiration check performed 0:00:02 ago on ... Package xxxx is already installed, skipping. ... (long delay, sometimes several minutes) ... Dependencies resolved. Nothing to do. Complete!
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
This happens to me every time. It seems to be when it is creating the completion cache that it spends all the time. It never used to happen, but I got install happy and installed the dnf-plugins-extras package. :-) Now from the end of the RPM transaction: to the program exit takes up to several minutes to complete. Or maybe it is the rpmconf checks. And I have lots of packages installed, so that could be a contributing factor, as well.
Nothing I do seems to change this delay.
I suggest using strace to find out where the delay is happening. I found a
bug where wonky mirrors were responsible for the hang, and made some adjustments to dnf to make it decidedly less tolerant of such mirrors.
https://bugzilla.redhat.com/show_bug.cgi?id=1294953
The more recent one bugging me is downloading those metadata files 2-3 times per day even after clean all (once right after is expected, but again 4 hours later no.)
Chris Murphy
On Wed, 30 Mar 2016 07:15:03 +0000 Chris Murphy lists@colorremedies.com wrote:
The more recent one bugging me is downloading those metadata files 2-3 times per day even after clean all (once right after is expected, but again 4 hours later no.)
Put this line in your /etc/dnf/dnf.conf file to get a delay of 12 hours. metadata_expire=43200
Or change the number to the amount of seconds you want.
On 03/29/2016 07:36 PM, CLOSE Dave wrote:
If I run something like, "dnf -y install xxxx", and xxxx is already installed, DNF gives a response like the following.
Last metadata expiration check performed 0:00:02 ago on ... Package xxxx is already installed, skipping. ... (long delay, sometimes several minutes) ... Dependencies resolved. Nothing to do. Complete!
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
I've seen and am seeing this happening many times, but I've given up complaining about it, because I feel feedback on the numerous defects dnf has, is politically unwanted.
Ralf
On 30. 3. 2016 at 06:35:19, Ralf Corsepius wrote:
On 03/29/2016 07:36 PM, CLOSE Dave wrote:
If I run something like, "dnf -y install xxxx", and xxxx is already installed, DNF gives a response like the following.
Last metadata expiration check performed 0:00:02 ago on ... Package xxxx is already installed, skipping.
... (long delay, sometimes several minutes) ...
Dependencies resolved. Nothing to do. Complete!
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
I've seen and am seeing this happening many times, but I've given up complaining about it, because I feel feedback on the numerous defects dnf has, is politically unwanted.
Feedback is always welcome, as long as it's constructive and both sides want to find mutually acceptable solution.
Thanks, Jan
On 03/30/2016 09:11 AM, Jan Zelený wrote:
On 30. 3. 2016 at 06:35:19, Ralf Corsepius wrote:
On 03/29/2016 07:36 PM, CLOSE Dave wrote:
If I run something like, "dnf -y install xxxx", and xxxx is already installed, DNF gives a response like the following.
Last metadata expiration check performed 0:00:02 ago on ... Package xxxx is already installed, skipping.
... (long delay, sometimes several minutes) ...Dependencies resolved. Nothing to do. Complete!
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
I've seen and am seeing this happening many times, but I've given up complaining about it, because I feel feedback on the numerous defects dnf has, is politically unwanted.
Feedback is always welcome, as long as it's constructive and both sides want to find mutually acceptable solution.
You certainly know that I am tired of hearing sentences like these. To me this, are all shallow and weak excuses.
As a German proverb says: "The bucket goes to the well until it breaks". Now the bucket is broken (read: my patience with dnf and the folks behind it is finally finished)
I am expecting Red Hat to finally take consequence on dnf and to stop shipping broken banana SW, such as dnf
Ralf
On Wed, Mar 30, 2016 at 09:53:01AM +0200, Ralf Corsepius wrote:
I am expecting Red Hat to finally take consequence on dnf and to stop shipping broken banana SW, such as dnf
Seriously, Ralf — this is not constructive.
On Tue, 29 Mar 2016 10:36:37 -0700, CLOSE Dave wrote:
That is, it works but it takes an unreasonably long time to do so. How can it be that, DNF knows the package is already installed and /still/ takes such a long time to decide that dependencies are ok? There aren't any dependencies to resolve!
One thing you can do is add a tab to your terminal, and either do "su - " to root, or use dnf with sudo. Then give your dnf commands (only), and go on with the previous activity. Then check back whenever you get good and ready to tell it y.
-
Beartooth -
Chris Murphy -
CLOSE Dave -
Honza Silhan -
Jan Zelený -
Joe Zeff -
Mark Haney -
Matthew Miller -
Ralf Corsepius -
Rick Stevens -
stan