Summary: | Sets still come from /etc/portage no matter what is defined for PORTAGE_CONFIGROOT | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Martin Gysel (bearsh) <me> |
Component: | Core - Configuration | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | esigra, rain |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=563836 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 144480 | ||
Attachments: |
add fallback value to parser for PORTAGE_CONFIGROOT
add PORTAGE_CONFIGROOT placeholder which gets expanded by the parser sets.conf.patch |
Description
Martin Gysel (bearsh)
2009-12-23 22:04:18 UTC
Created attachment 214004 [details, diff]
add fallback value to parser for PORTAGE_CONFIGROOT
Created attachment 214005 [details, diff]
add PORTAGE_CONFIGROOT placeholder which gets expanded by the parser
Using patches from comment 1 and 2 portage also scans sets in PORTAGE_CONFIGROOT. this means there are now the sets from /etc/portage/sets AND ${PORTAGE_CONFIGROOT}/etc/portage/sets maybe there's another solution to prevent this behavior Created attachment 214009 [details, diff]
sets.conf.patch
A fixed sets.conf.patch file. The previous one had "setc" instead of "/etc".
The issue of portage still looking to real root appears to me an issue of portage not using PORTAGE_CONFIGROOT for all portage paths, just for /etc. Even then, PORTAGE_CONFIGROOT isn't always set to the environment variable. The function load_default_config, under portage/_sets/__init__.py in portage v2.1.6.13, is called twice, the first time honoring the user's PORTAGE_CONFIGROOT, and the second not. If I modify the load_default_config function like this: --- begin --- def load_default_config(settings, trees): setconfigpaths = [os.path.join(GLOBAL_CONFIG_PATH, "sets.conf")] setconfigpaths.append(os.path.join(settings["PORTDIR"], "sets.conf")) setconfigpaths += [os.path.join(x, "sets.conf") for x in settings["PORTDIR_OVERLAY"].split()] setconfigpaths.append(os.path.join(settings["PORTAGE_CONFIGROOT"], USER_CONFIG_PATH.lstrip(os.path.sep), "sets.conf")) print("PORTAGE_CONFIGROOT: " + settings["PORTAGE_CONFIGROOT"]) # addition for path in setconfigpaths: # addition print (path) # addition return SetConfig(setconfigpaths, settings, trees) --- end --- I get the following output using portage v2.1.6.13: --- begin --- $ sudo PORTAGE_CONFIGROOT=~/test/ ROOT=~/test/ emerge -pv portage PORTAGE_CONFIGROOT: /home/jacob/test/ /usr/share/portage/config/sets.conf /usr/portage/sets.conf /home/jacob/test/etc/portage/sets.conf PORTAGE_CONFIGROOT: / /usr/share/portage/config/sets.conf /usr/portage/sets.conf /usr/local/portage/layman/sunrise/sets.conf /usr/local/portage/layman/gnome/sets.conf /usr/local/portage/sets.conf /etc/portage/sets.conf These are the packages that would be merged, in order: [...snip...] --- end --- (In reply to comment #4) > Created an attachment (id=214009) [details] > sets.conf.patch > > A fixed sets.conf.patch file. The previous one had "setc" instead of "/etc". > what's wrong with my patch? according to http://docs.python.org/library/configparser.html the placeholder ist '%(bar)s' which then gets replaced to foo. in our case, foo is PORTAGE_CONFIGROOT var in portage which afaik should end with '/' %(PORTAGE_CONFIGROOT)setc/portage/sets/ -> e.g. /usr/armv7a-unknown-linux-gnueabi/etc/portage/sets/ anyway, thx for your great help digging through portage! Comment on attachment 214009 [details, diff]
sets.conf.patch
Sorry, I was mistaken about those corrections I applied.
(In reply to comment #1) > Created an attachment (id=214004) [details] > add fallback value to parser for PORTAGE_CONFIGROOT (In reply to comment #2) > Created an attachment (id=214005) [details] > add PORTAGE_CONFIGROOT placeholder which gets expanded by the parser Thanks, that's in svn r15307. This is fixed in 2.2_rc64. *** Bug 266132 has been marked as a duplicate of this bug. *** |