The only way to handle blockers seems to be to unmerge the blocker and restart
emerge. The unmerged package may, and probably will, break applications for the
time of the recompile. Instead, portage could move the files and libraries that
it would (auto)unmerge to a temporary bin/lib/var and prefix
PATH/LD_LIBRARY/PATH in profile (or similar) for the benefit of not yet loged-in
users (or those who accept login in again to gain access that the unmerged blocker).
Steps to Reproduce:
Better (or just easier) would be to compile and install (but not merge) the
blocked package, unmerge the blocking package, and finally merge the blocked
i dont think it's a good idea to take this kind of action ...
blockers are not always resolved by unmerging blocking packages and then
merging what you wanted to in the first place
"Better (or just easier) would be to compile and install (but not merge)
the blocked package, unmerge the blocking package, and finally merge the
Is that even possible? If, which is not uncommon, the blocker is a library
then there are header files that goes with it. Some header files may have
the same name in both the blocked and the blocker (which may be the origin
of the conflict even) and the blocked package will probably not compile
unless the contents are identical.
That's how I tend to resolve blockers; ebuild thingy-0.01.ebuild merge &&
emerge -C realthingy && emerge =thingy-0.0.1. If thingy does pick up headers
from realthingy that's probably a bug in thingy; a) because it should read
its own headers, and then the system's; and b) because it shouldn't use the
same #define headerguards.
<lv> jstubbs, ping
<jstubbs> lv: pong
<lv> jstubbs: i have a feature request.
<lv> a dep of some kind that will auto-unmerge blockers
<lv> installing linux26-headers should auto-unmerge linux-headers
<lv> so i think it would be a useful feature to have
<lv> how much stress would it be to implement something like that?
my idea would be to add a new depend type that would specifically allow portage to unmerge a blocker, and keep the default blocking behavior.
*** This bug has been marked as a duplicate of 79606 ***