i could see issuing a warning to stderr, but these shouldn't traceback ... quite a good amount of information can still be provided if these things are unreadable. # mkdir -p /etc/portage/package.keywords/ # chmod 0 /etc/portage/package.keywords/ $ portageq envvar CHOST Traceback (most recent call last): File "/usr/bin/portageq", line 834, in <module> main() File "/usr/bin/portageq", line 815, in main retval = function(args) File "/usr/bin/portageq", line 664, in envvar print(portage.settings[arg]) File "/usr/lib64/portage/pym/portage/proxy/objectproxy.py", line 37, in __getitem__ return object.__getattribute__(self, '_get_target')()[key] File "/usr/lib64/portage/pym/portage/__init__.py", line 588, in _get_target return _get_legacy_global(name) File "/usr/lib64/portage/pym/portage/_legacy_globals.py", line 34, in _get_legacy_global portage.db = portage.create_trees(**kwargs) File "/usr/lib64/portage/pym/portage/__init__.py", line 476, in create_trees config_incrementals=portage.const.INCREMENTALS) File "/usr/lib64/portage/pym/portage/proxy/objectproxy.py", line 31, in __call__ return result(*args, **kwargs) File "/usr/lib64/portage/pym/portage/package/ebuild/config.py", line 531, in __init__ local_config, global_accept_keywords=self.configdict["defaults"].get("ACCEPT_KEYWORDS", "")) File "/usr/lib64/portage/pym/portage/package/ebuild/_config/KeywordsManager.py", line 57, in __init__ verify_eapi=False) File "/usr/lib64/portage/pym/portage/util/__init__.py", line 408, in grabdict_package pkgs=grabdict(myfilename, juststrings, empty=1, recursive=recursive) File "/usr/lib64/portage/pym/portage/util/__init__.py", line 356, in grabdict for x in grablines(myfilename, recursive): File "/usr/lib64/portage/pym/portage/util/__init__.py", line 470, in grablines dirlist = os.listdir(myfilename) File "/usr/lib64/portage/pym/portage/__init__.py", line 215, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 13] Permission denied: '/etc/portage/package.keywords' $ emerge --info Traceback (most recent call last): File "/usr/bin/emerge", line 43, in <module> retval = emerge_main() File "/usr/lib64/portage/pym/_emerge/main.py", line 1517, in emerge_main settings, trees, mtimedb = load_emerge_config() File "/usr/lib64/portage/pym/_emerge/actions.py", line 2969, in load_emerge_config trees = portage.create_trees(trees=trees, **kwargs) File "/usr/lib64/portage/pym/portage/__init__.py", line 476, in create_trees config_incrementals=portage.const.INCREMENTALS) File "/usr/lib64/portage/pym/portage/proxy/objectproxy.py", line 31, in __call__ return result(*args, **kwargs) File "/usr/lib64/portage/pym/portage/package/ebuild/config.py", line 531, in __init__ local_config, global_accept_keywords=self.configdict["defaults"].get("ACCEPT_KEYWORDS", "")) File "/usr/lib64/portage/pym/portage/package/ebuild/_config/KeywordsManager.py", line 57, in __init__ verify_eapi=False) File "/usr/lib64/portage/pym/portage/util/__init__.py", line 408, in grabdict_package pkgs=grabdict(myfilename, juststrings, empty=1, recursive=recursive) File "/usr/lib64/portage/pym/portage/util/__init__.py", line 356, in grabdict for x in grablines(myfilename, recursive): File "/usr/lib64/portage/pym/portage/util/__init__.py", line 470, in grablines dirlist = os.listdir(myfilename) File "/usr/lib64/portage/pym/portage/__init__.py", line 215, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 13] Permission denied: '/etc/portage/package.keywords'
(In reply to comment #0) > i could see issuing a warning to stderr, but these shouldn't traceback ... How about if we just show an "Access Denied" message? > quite a good amount of information can still be provided if these things are > unreadable. But whatever information they can get is probably none of their business if they don't have access to all portage config files. We could try to construct a partial config instance, but then it could potentially return erroneous results for some queries.
(In reply to comment #1) it might be accurate information, it might not. for most package.* paths, it won't matter at all to `portageq envvar` or most (if not all) of `emerge --info`. i think that's up to the user to determine. if we issued a warning to stderr that said: warning: access denied while accessing: <path> warning: information displayed might not be accurate
By parsing package.keywords on demand, we don't even have to show an error message until it's accessed: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b03ed0de134456870c0361dd573e18830c45fa49
Parse package.mask/unmask on demand: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=09980f19e584b644b9e2cf4d5e1e0369b6062ca1
ah, that's a good solution too :)
Some of these config files support */* wildcard settings that are translated to global environment settings, making it trickier to load them on demand: package.license -> ACCEPT_LICENSE package.properties -> ACCEPT_PROPERTIES package.env -> any variable package.accept_keywords -> ACCEPT_KEYWORDS This one's currently not implemented: package.accept_keywords -> ACCEPT_KEYWORDS
(In reply to comment #6) i'd like to think that the variables affected there are in the minority of requested ones. so if the loading code simply warned on those, that'd be fine. package.env would only matter if someone was specifically querying the info for that right ? so generally `portageq ...` and `emerge --info` don't care about package.env.
I think we can just drop the */* wildcard to global var translation, in order to make everything lazy. It makes sense to do so, regardless of the permission thing.
(In reply to comment #8) > I think we can just drop the */* wildcard to global var translation, in > order to make everything lazy. It makes sense to do so, regardless of the > permission thing. Please don't do that. Specifying global settings like this is a much better approach than using global variables from make.conf + config files. Using config files only is much cleaner. If you want to drop something, drop the variables. I migrated all my systems long ago to not use variables in make.conf and I'd prefer that this doesn't break. What exactly is the problem with requiring /etc/portage to be readable? Either you're allowed to access portage's config in which case you may use emerge --info. Or someone didn't want you to access portage's config files. Portage should not try to circumvent this.
Can we close this bug as resolved now? The issue described in the original post is no longer present.
All potential files should be checked (also in /var/cache/edb and /var/lib/portage). /etc/portage/modules: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=5924b7afae7c731abc24a0e16fcd103e680e3e5b
if i find another case, i'll file a new bug
