Bug 1410388

Summary:	metadata_expire is not honored during installation in mock
Product:	[Fedora] Fedora	Reporter:	Vít Ondruch <vondruch>
Component:	dnf	Assignee:	rpm-software-management
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	26	CC:	jdisnard, jmracek, mebrown, msimacek, msuchy, packaging-team-maint, praiskup, rpm-software-management, vmukhame, vondruch, williams
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-10 13:57:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ***