The `portageq repositories_configuration <eroot>` command is intended to query repository configuration for <eroot>, but it does not override the PORTAGE_CONFIGROOT variable internally, so the <eroot> parameter is essentially ignored.
Setting PORTAGE_CONFIGROOT works well if the repository location settings refer to existing directories. However, if the <eroot> parameter refers to a chroot, and the repository location settings valid only for a chrooted process, then RepoConfigLoader's repository location validation gives annoying results. It seems like portageq should probably disable the location validation, and simply allow the configuration to pass through as-is.
Patch posted for review: https://archives.gentoo.org/gentoo-portage-dev/message/e2a736156b5d95f5c7b1821618c6d5aa https://github.com/gentoo/portage/pull/278
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=382f4be415394886026ccd5dcd08ca96ecda31fa commit 382f4be415394886026ccd5dcd08ca96ecda31fa Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-03-23 16:29:13 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2018-03-26 17:42:50 +0000 portageq repos_config: fix <eroot> parameter (bug 648062) The <eroot> parameter is ineffective for commands that query configuration, since the PORTAGE_CONFIGROOT variable controls the location of configuration files. Therefore, for portageq repos_config, implicitly set PORTAGE_CONFIGROOT equal to the value of the <eroot> parameter. Note that this works correctly for both prefix and non-prefix systems, because both EROOT and PORTAGE_CONFIGROOT are supposed to include the EPREFIX offset. Bug: https://bugs.gentoo.org/648062 bin/portageq | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)}
Fixed in portage-2.3.40-r1.
