Hopefully someone can help fix up that bug summary to be a little clearer if I add some more info here. Currently when portage encounters a soft blocker (as an example, i'll use openrc-0.13.8.ebuild's dep/block of !<sys-fs/udev-init-scripts-27), it seems to often "fix" that blocker very very late in the emerge order. In this example, in a large world upgrade, openrc may be among the first packages upgraded, then there are 100-200 other package upgrades, THEN near the end, udev-init-scripts is upgraded to a suitable version. If *any* of the 100-200 package in between those causes emerge to die, the user has a broken system... if he were to reboot in this state, things would be very broken I think it would make sense to try to remedy the blocker situation as early as possible, in other words have udev-init-scripts ideally be the next thing upgraded after openrc. But there may be some cases in thinking of where the opposite is true, where having the blocker upgrade happen as late as possible would be ideal. As another similar example, eselect-opengl-1.3.1-r1 is blocked by !<media-libs/mesa-10.3.4-r1, but there can again be a few hundred packages upgraded between the eselect-opengl upgrade and the mesa upgrade. If any of those packages uses the opengl headers whose handling changed with this eselect-opengl/mesa upgrade pair, they will fail to build. Again in this case, having the blocker upgraded as early as possible after the blockee would be helpful. Let me know if any of this needs clarifying. Thanks!
*** This bug has been marked as a duplicate of bug 256870 ***
This isn't exactly a duplicate of bug 256870, since that one is about different slots of the same package that block each other, which is a very specific case.
We may be able to optimize the merge order to minimize this issue, but it will never be perfect. The only fail-safe solution is to use filesystem-level snapshots, as noted in bug #40127, comment #11.
