With recent gcc-4.4 stabilization, I have been running "emerge -e world" in my systems to be able to remove old gcc safely (as talked in http://www.gentoo.org/doc/en/gcc-upgrading.xml#doc_chap2 ). With this, I have noticed that I could have saved a lot of time if portage were able to skip precompiled packages (like flash-player, lots of huge games, firefox-bin...) that doesn't need to be re-emerged in cases like this simply running, for example, "emerge -e world --jobs=4 --keep-going --accept-properties=-precompiled") Thanks a lot for thinking about this :-) Reproducible: Always
This could probably be handled with "MERGE_TYPE=binary" from eapi4 :-/ http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
(In reply to comment #0) > With recent gcc-4.4 stabilization, I have been running "emerge -e world" in my > systems to be able to remove old gcc safely (as talked in > http://www.gentoo.org/doc/en/gcc-upgrading.xml#doc_chap2 ). With this, I have > noticed that I could have saved a lot of time if portage were able to skip > precompiled packages (like flash-player, lots of huge games, firefox-bin...) > that doesn't need to be re-emerged in cases like this simply running, for > example, "emerge -e world --jobs=4 --keep-going > --accept-properties=-precompiled") The --accept-properties=-precompiled thing would work without any changes to portage. You'd just have to be set the appropriate PROPERTIES value in all of the relevant ebuilds. This is really something that should be documented/specified in PMS. (In reply to comment #1) > This could probably be handled with "MERGE_TYPE=binary" from eapi4 :-/ > http://devmanual.gentoo.org/ebuild-writing/eapi/index.html MERGE_TYPE=binary applies to a different kind of "precompiled package", like the those that emerge creates from *any* ebuild when the --buildpkg option is enabled.
Offhand, this seems like the wrong tact- the correct way of handling this is backtracking whatever depends on gcc (meaning we eliminate implicit system dep). Reason I say this is that such an approach, implemented sanely, would allow rebuilding python targets, perl targets, etc. Or we add in PROPERTIES=precompiled which has a murky interpretation...
Please define what is meant by "precompiled". Does this apply to C/C++ only, or other languages too? What about documentation built from various source formats? (In reply to Brian Harring from comment #3) > Offhand, this seems like the wrong tact- the correct way of handling this is > backtracking whatever depends on gcc (meaning we eliminate implicit system > dep). > > Reason I say this is that such an approach, implemented sanely, would allow > rebuilding python targets, perl targets, etc. Or we add in > PROPERTIES=precompiled which has a murky interpretation... I agree. Closing for now, since this appears to be rather vague (and in addition, there is no progress in this bug since several years).
