Bug 1304036

Summary:	When using alternate install root, vars from /etc/dnf/vars are not read in
Product:	[Fedora] Fedora	Reporter:	Pat Riehecky <riehecky>
Component:	dnf	Assignee:	Jaroslav Mracek <jmracek>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jsilhan, mluscon, packaging-team-maint, pnemade, riehecky, vmukhame
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-02-15 12:43:02 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 Pat Riehecky 2016-02-02 17:46:40 UTC

Description of problem:
When using DNF to setup an area for systemd-nspawn using DNF to bootstrap the base, vars from /etc/dnf/vars on the system (not the installroot) do not seem to be expanded.

Version-Release number of selected component (if applicable):dnf-1.1.6-1.fc24


How reproducible:100%


Steps to Reproduce:
1.echo 24 > /etc/dnf/vars/dockerreleasever 
2.create new repo that uses $dockerreleasever rather than $releasever
3.dnf --installroot=/btrfs/dockerbase --disablerepo=* --enablerepo="repo from step 2" install fedora-release

Actual results:
$dockerreleasever is not expanded

Expected results:
$dockerreleasever expanded from system's /etc/dnf/vars

Additional info:
Similar fix from yum:
http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=22271bf34e71bbfc75d0a59354fc0108e004f36c

Comment 1 Jaroslav Mracek 2016-02-08 12:51:23 UTC

I think the problem is in path /etc/dnf/vars/dockerreleasever . With --installroot the vars should be taken from installroot. Therefore the path should looks like /btrfs/dockerbase/etc/dnf/vars/dockerreleasever.
This is same for releasever. It is taken from --installroot. Please could you try supposed solution and report result?
Thanks a lot

Comment 2 Pat Riehecky 2016-02-12 14:58:05 UTC

Hello,

I agree the nature of the problem is in the path.  However, the issue itself appears in part because the repos are read from /etc/ while the vars are read from /btrfs/dockerbase/etc/.

This is inconsistent behavior.  I'd expect that the vars are read from /etc/ first and then any values found in /btrfs/dockerbase/etc/ are set (replacing any values already defined from /etc/).

My thoughts on the matter mostly run towards, why are repos read in from one path but the vars are not?

Following my replication steps above:
1.echo 24 > /etc/dnf/vars/dockerreleasever 
2.create new repo that uses $dockerreleasever rather than $releasever

This works as $dockerreleasever is defined
dnf --disablerepo=* --enablerepo="repo from step 2" install fedora-release

This does not as /etc/dnf/vars is never consulted
dnf --installroot=/btrfs/dockerbase --disablerepo=* --enablerepo="repo from step 2" install fedora-release

I find this discrepancy a bit weird.  The only difference to my mind is what to do with the rpms once they are pulled down.

I've tossed a (somewhat sloppy) patch up at github that resolves: https://github.com/rpm-software-management/dnf/pull/434

Comment 3 Jaroslav Mracek 2016-02-15 12:43:02 UTC

Thanks to your comment. We prepared new pull-request that will make behavior of installroot more consistent. Please try it at https://github.com/rpm-software-management/dnf/pull/428 . We also added description that as we think it will help most of users. The changes are as follows - repos, dnf.conf, vars and so on are taken from installroot. If vars will be taken from host there will be problems if someone will try for example to install in installroot something from other distribution.

I think that the discussion will be better to move to the pull-request 428. For now I am going to close this bug report. Anyway thank you for your suggestions and please make comments to pullrequest 428 if you will feel uncomfortable with proposed changes.
Thanks a lot.