If I define PORTAGE_CONFIGROOT e.g. for cross-compiling I'm not able to put sets into ${PORTAGE_CONFIGROOT}/etc/portage/sets, sets are always taken from /etc/portage/sets Reproducible: Always Steps to Reproduce: 1. use PORTAGE_CONFIGROOT with emerge @some_set Actual Results: only looks for sets in /etc/portage Expected Results: use sets in ${PORTAGE_CONFIGROOT}/etc/portage/sets example: (neuvoo) gorilla / # ls /usr/armv7a-unknown-linux-gnueabi/etc/portage/sets/ cc_libs x11_proto (neuvoo) gorilla / # ls /etc/portage/sets/ cc_libs (neuvoo) gorilla / # emerge-armv7a-unknown-linux-gnueabi --list-sets cc_libs downgrade installed live-rebuild module-rebuild preserved-rebuild security selected system unavailable world (neuvoo) gorilla / #
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. ***
