Summary: | unreadable /etc/portage/ files shouldn't kill portageq/emerge/etc... | ||
---|---|---|---|
Product: | Portage Development | Reporter: | SpanKY <vapier> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | Keywords: | InVCS |
Priority: | Low | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 484436 |
Description
SpanKY
2012-06-01 05:23:47 UTC
(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 |