Problem: 1) Cross compiles can result in miscompiles on the host system. 2) Using PORTAGE_CONFIGROOT= portage still reads portage settings from / 3) Maintainers don't know how to use DEPEND vs RDEPEND correctly. So a common case for number 1 You set up a emerge to pass PORTAGE_CONFIGROOT=/somedir Inside of the PORTAGE_CONFIGROOT you have a 100% setup for cross compiling as it was designed for. So it sets up ARCH= ACCEPT_KEYWORDS= ROOT= and all the other required jazz. You then begin to cross emerge packages. This goes well for most base system stuff. The problems begin when ROOT!=/ and emerge wants to satisfy DEPEND= on / and in ROOT=/somedir. This is clearly a problem for a number of reasons. Packages that are in DEPEND when merging into a ROOT=/somedir cause you to have to keywords ~anotherarch vs the one you are trying to cross compile for. IE you have to package.keyword on / and in the $PORTAGE_CONFIGROOT. Some depend graphs will never be resolvable. Solutions: 1) When PORTAGE_CONFIGROOT is defined. emerge/portage should 100% respect it and not read from /etc/portage/. This is verified by doing an PORTAGE_CONFIGROOT=/somedir strace -o /dev/stdout -eopen emerge -pvq anypkg \ | grep /etc 1.1) When ROOT= is given portage/emerge should respect it and only use the var/db/pkg/ files from that dir. 2) extend the existing --with-bdeps=(y|n) option.. Maybe (Y|N) options? kinda like -k/-K/-g/-G 3) introduce env variable in the PORTAGE_CONFIGROOT/etc/make.conf that tells emerge how not to behave. 4) Open to ideas that fix the problem quickly and don't introduce --some-super-duper-long-command-line-option. When these options behave this way portage is one hell of a powerful tool that can arbitrarly build nearly anything. We just need to put a little trust in the end-user to notice things like "hey unzip" I probably need that..
huh.... i'm just fighting with prefixed portage (so no embedded :)), to get it to behave the same with EPREFIX=/somepath as with ROOT=/somepath dependency resolution wise. I want to build into another prefix, but have DEPENDS resolved from the "main" prefix too, if they are there - just like ROOT=/blah does.... for me this makes a lot of sense. i even require it, or i'll have to deal with package.provided in my new prefix, since it's a platform where most of @system for example is not buildable. my case is this: i have an interix prefix (which uses the interix libc). i want a windows prefix (which uses the windows libc, and are executable on the build machine, just like the interix binaries). Compiler and linker for this task is in place an works, also merging with EPREFIX=/blah emerge -pv blah works perfectly, except that (of course) portage wants to emerge a whole bunch of deps. those deps (of course only DEPEND, not {R,P}DEPEND) have to be resolved from the interix prefix, otherwise i would have to put tons of packages in the package.provided, which clearly is no good solution...
*** Bug 261109 has been marked as a duplicate of this bug. ***
This is solved with svn r13245 with two new options --rdeps-only and --root-deps
Created attachment 186932 [details, diff] new options: --root-deps[=rdeps] This is in svn r13267.
(In reply to comment #4) > Created an attachment (id=186932) [edit] > new options: --root-deps[=rdeps] > > This is in svn r13267. > Just tried this new option with portage-2.2_rc30, and it apears to work fine.
It's also in portage-2.1.6.12 now.
This feature has been working great. It's now become a time tested good feature. Not the ideal solution long run but till perl's build system along with a few others is resolved this prevents many headaches. It progressed embedded/gen2's ability to support projects such as chromium-os.
