Bug 1410388 - metadata_expire is not honored during installation in mock
Summary: metadata_expire is not honored during installation in mock
Keywords:
Status: CLOSED DUPLICATE of bug 1293910
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 26
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-05 11:45 UTC by Vít Ondruch
Modified: 2017-07-10 13:57 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-10 13:57:35 UTC
Type: Bug


Attachments (Terms of Use)

Description Vít Ondruch 2017-01-05 11:45:38 UTC
Description of problem:
It seems that the metadata_expire is not reflected. According to documentation, the default timeout should be 48h, but using dnf with mock, the metadate are refreshed almost always (there doesn't look to be any pattern, sometimes they are refreshed and the other time they are not). Changing the configuration option in mock config does not look to have any influence.

Moreover, I'd say that the value of 0 used to mean don't expire the metadata, now it seems that -1 should provide the same service (but it does not).


Version-Release number of selected component (if applicable):
$ rpm -q dnf
dnf-2.0.0-2.fc26.noarch


How reproducible:


Steps to Reproduce:
1. $ mock -r fedora-rawhide-x86_64 rubygem-multi_xml-0.6.0-1.fc26.src.rpm -n
2.
3.

Actual results:
The metadata are refreshed every now and then.


Expected results:
The metadata are not refreshed until 48h passed. The metadata_expire should allow to control the timeout.


Additional info:

Comment 1 Honza Silhan 2017-01-09 15:30:32 UTC
Are you building packages again from the same buildroot for the same architecture, distro and release?

It works for me:
1) dnf download --source rubygem-multi_xml
2) dnf download --source acpi
3) mock -r fedora-rawhide-x86_64 rubygem-multi_xml-0.5.5-4.fc24.src.rpm -n
4) mock -r fedora-rawhide-x86_64 acpi-1.7-5.fc24.src.rpm  -n

Step 4 runs blazingly fast.

Comment 2 Vít Ondruch 2017-01-09 16:41:37 UTC
I am building still the same package. And I typically develop on such package, so for me it is more like:

1) fedpkg srpm
2) mock -r fedora-rawhide-x86_64 rubygem-multi_xml-0.5.5-4.fc24.src.rpm -n
3) fedpkg srpm
4) mock -r fedora-rawhide-x86_64 rubygem-multi_xml-0.5.5-4.fc24.src.rpm -n

But of course there is typically some adjustment of the package in between, so there might be some delays such as 1 minute between builds.

And yes, sometimes the cache is not refreshed and sometimes it is. I can't see any pattern in the behavior.

BTW I have enable the "local" repository if that makes any difference.

Comment 3 Vít Ondruch 2017-01-16 15:37:53 UTC
With jsilhan, we tried some test and did not find any reason why this should happen. We were not able to reproduce this outside of mock, while it was reproducible in mock. So this might be some change in mock. Changing the component ...

Comment 4 Miroslav Suchý 2017-01-17 08:17:41 UTC
It happen for me (on F25) with just pure DNF. The fedora repo is NOT downloaded again, but the "local" repo is downloaded always again.

[msuchy@dri/~/projects/mock{devel}]$ sudo '/usr/bin/dnf' '--installroot' '/var/lib/mock/fedora-rawhide-x86_64/root/' '--releasever' '26' '--disableplugin=local' '--setopt=deltarpm=false' 'install' '@buildsys-build'
local                                                                                                                   398 kB/s |  48 MB     02:03    
Poslední kontrola metadat: před 0:01:09, Tue Jan 17 09:10:25 2017.
Skupina 'Skupina nástrojů pro tvorbu (balíčků) systému' je již nainstalována, přeskakuji.
Závislosti vyřešeny.
Není co dělat
Hotovo!
[msuchy@dri/~/projects/mock{devel}]$ sudo '/usr/bin/dnf' '--installroot' '/var/lib/mock/fedora-rawhide-x86_64/root/' '--releasever' '26' '--disableplugin=local' '--setopt=deltarpm=false' 'install' '@buildsys-build'
local                                                                                                                   559 kB/s |  48 MB     01:27    
Poslední kontrola metadat: před 0:01:00, Tue Jan 17 09:13:14 2017.
Skupina 'Skupina nástrojů pro tvorbu (balíčků) systému' je již nainstalována, přeskakuji.
Závislosti vyřešeny.
Není co dělat
Hotovo!
[msuchy@dri/~/projects/mock{devel}]$ rpm -q dnf
dnf-1.1.10-4.fc25.noarch

Comment 5 Honza Silhan 2017-01-23 13:55:14 UTC
Well, it was reported on DNF-2.0 and mock-1.3.3. we will examine DNF-2.0 again with local repo enabled with steps in comment 4.

Comment 6 Fedora End Of Life 2017-02-28 10:52:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 7 Jaroslav Mracek 2017-06-27 16:41:28 UTC
Please Miroslav, can you reproduce it with dnf-2.5.1? I tried it on my Fedora 25, but with something close to upstream version of dnf(2.5.1), but I was unable to reproduce the issue. Believe that you can have another setting. Thanks a lot.

Comment 8 Vít Ondruch 2017-06-28 09:49:20 UTC
What is the relation to bug 1293910?

Comment 9 Miroslav Suchý 2017-07-10 13:57:35 UTC
I agree with Vit that this is likely dupe of 1293910.
And with enabled local and metadata_expire=0 I do not see any additional downloads.

*** This bug has been marked as a duplicate of bug 1293910 ***


Note You need to log in before you can comment on or make changes to this bug.