Red Hat Bugzilla – Bug 1279185
dnf searches in /etc/yum.repos.d/*.repo when using --installroot
Last modified: 2016-10-04 15:14:33 EDT
I hit a strange behaviour, when using dnf with the --installroot option.
To explain it better, let's use yum for this example:
yum update --installroot=/<somepath>
When issuing this command, the following happens:
1) yum uses the repo files located in /<somepath>/etc/yum.repos.d/.*repo
2) yum uses the cache of /<somepath>/cache/yum.... to store the metadata
3) yum uses the cache of /<somepath>/cache/yum.... to store updated nevra
4) yum uses the cache of /<somepath>/lib/yumdb... to store the db entries
With other words, using --installroot does a full context switch (as I explain it) to a different "root". Not touching the underlaying systems yum.repos.d etc.
This has the advantage, that I can use the real host system (the true one in /) to update a different system (one for systems integration, different updates or other related tasks) in --installroot (which of course can have other .*repo files, other activated ones or disabled ones or other added ones.
When using dnf otoh, it does only steps 2 - 4... sadly dnf searches in the true / (root) directory for repo files. Thus ignoring the repo files found in /<somepath>/yum.repos.d/*.repo.
Temporarely (and contradicting to yum) I have to temporarely copy over the files found in /<somepath>/yum.repos.d/.*repo to /etc/yum.repos.d/ whenever issuing the --installroot command.
With other words... dnf is not correctly switching the context ... when I intend dealing with a different --installroot, then I not only want to store the metadata, cache, downloaded nevra in the installroot but also use the repo files found in the installroots /etc/yum.repos.d directory.
Thanks for the report. We'll take look.
This behavior is fixed by pull-request https://github.com/rpm-software-management/dnf/pull/428
*** Bug 1160612 has been marked as a duplicate of this bug. ***
*** Bug 1304887 has been marked as a duplicate of this bug. ***
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see email@example.com with any questions
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.
Fixed as part of DNF 2.0 which will be available at some point in the near future.