Hey Another one i found with -j*: i have a virtual with many dependencies in our company-private overlay. one of the deep dependencies somewhere in the middle is boost. Now if i start to merge the whole bunch (on winnt, but that should not matter for portage, right ;)), and it comes to boost, i'm getting an error, that zlib.h is not found. zlib is the first package portage emerges, but it is not installed. boost most of the time is somewhere around package 60, and has DEPEND and RDEPEND set on zlib. shouldn't portage wait with starting the boost build, until zlib is installed...? just as a side note: on windows there is no real @system (because most of the packages cannot be merged anyway), so i'm starting with a nearly empty prefix here (only baselayout, gcc-config, libtool and prefix-chain-utils are installed). do i have to tweak my system set, so that zlib (or possibliy others) are treated correctly here? i feel that portage should enforce DEPENDS beeing there before starting a build even with system packages. i know it does not install system packages while anything else is building. but then portage simply has to delay starting boost build until zlib _is_ installed, right (no matter whether it is @system or not...)?
I think this boils down to Diego's long standing quest to get all dependencies explicit. As long as we assume that @system is installed we get these kinds of problems (as you also know from the other bootstrap documents for Gentoo Prefix).
when we're at it: i'd need another dependency class: BINARY-RUNTIME-DEPEND. which means that an executable (in contrast to a library) is required, so the ABI of that executable can be different. i'd need this for clean dependencies with prefix-chaining...
(In reply to comment #1) > I think this boils down to Diego's long standing quest to get all dependencies > explicit. As long as we assume that @system is installed we get these kinds of > problems (as you also know from the other bootstrap documents for Gentoo > Prefix) But the explicit zlib dep is already in all boost ebuilds, isn't it? It's in the ones I'm looking at now... so I'm not sure what you're talking about here. Anyway, the scheduler should have respected the zlib dep if it was in fact inside DEPEND, so I'd like to see some --debug output for the emerge dependency calculation.
Created attachment 211856 [details] winnt dependency debug output owh damn... i just realized that this is probably my own fault; we're using prefix-chaining (that freaky patch i wrote for prefix-portage ;)), and that make portage find DEPENDs from a parent prefix. so portage thinks the DEPEND is already merged, and continues, however zlib is not merged in _the current_ prefix (required to fullfill a RDEPEND in my case). i guess i'm back to some portage hacking; something like waiting for RDEPEND to be there before merging too. anyway - just FYI the debug output ;)
pfff... i fail on reading _emerge/depgraph.py:_serialize_tasks, which i believe would be the correct place to (hackishly, and just until i have a better solution, and just internal to our company - so no fear) force portage to wait for RDEPENDS beeing merged too. am i in the right place? and i believ asking you is faster: which one of the dependecy priorities do i have to adjust to make this work the way i want it...? Thanks... going to take a short portage/python timeout to cure my headaches ;)
(In reply to comment #5) > pfff... i fail on reading _emerge/depgraph.py:_serialize_tasks, which i believe > would be the correct place to (hackishly, and just until i have a better > solution, and just internal to our company - so no fear) force portage to wait > for RDEPENDS beeing merged too. am i in the right place? and i believ asking > you is faster: which one of the dependecy priorities do i have to adjust to > make this work the way i want it...? It already does wait for RDEPEND unless there are circular deps that are otherwise unsolvable, and I guess you probably don't want to trigger some unsolvable circular deps. Anyway, ignoring this problem, you'd want to set DepPriorityNormalRange.MEDIUM = DepPriorityNormalRange.MEDIUM_SOFT, DepPrioritySatisfiedRange.MEDIUM = DepPrioritySatisfiedRange.MEDIUM_SOFT, and modify DepPriority.__int__() to return 0 for runtime deps.
(In reply to comment #6) > (In reply to comment #5) [snip] > It already does wait for RDEPEND unless there are circular deps that are > otherwise unsolvable, and I guess you probably don't want to trigger some > unsolvable circular deps. hm. somehow i can't imaging how zlib and boost could create a circle ;) maybe after all still a problem in the portage code, and not in my patch? it's rather hard for me to trace the problem - but i'll keep trying :) > > Anyway, ignoring this problem, you'd want to set DepPriorityNormalRange.MEDIUM > = DepPriorityNormalRange.MEDIUM_SOFT, DepPrioritySatisfiedRange.MEDIUM = > DepPrioritySatisfiedRange.MEDIUM_SOFT, and modify DepPriority.__int__() to > return 0 for runtime deps. > ok, thanks - i'll have a look at it.
