Bug 1304036 - When using alternate install root, vars from /etc/dnf/vars are not read in
When using alternate install root, vars from /etc/dnf/vars are not read in
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaroslav Mracek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-02 12:46 EST by Pat Riehecky
Modified: 2016-02-15 07:43 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-15 07:43:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pat Riehecky 2016-02-02 12:46:40 EST
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 07:51:23 EST
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 09:58:05 EST
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 07:43:02 EST
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.

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