Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 537080 - soft blockers are remedied dangerously late in emerge order
Summary: soft blockers are remedied dangerously late in emerge order
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Dependencies (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
Depends on:
Blocks: 300071 256870
  Show dependency tree
Reported: 2015-01-19 20:41 UTC by Ben Kohler
Modified: 2015-01-20 06:26 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Ben Kohler gentoo-dev 2015-01-19 20:41:24 UTC
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.

Comment 1 Zac Medico gentoo-dev 2015-01-19 23:04:40 UTC

*** This bug has been marked as a duplicate of bug 256870 ***
Comment 2 Zac Medico gentoo-dev 2015-01-19 23:08:13 UTC
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.
Comment 3 Zac Medico gentoo-dev 2015-01-19 23:28:38 UTC
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.