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:
The bug has been referenced in the following commit(s):
Author: Zac Medico <firstname.lastname@example.org>
AuthorDate: 2018-03-23 16:29:13 +0000
Commit: Zac Medico <email@example.com>
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.
bin/portageq | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)}
Fixed in portage-2.3.40-r1.