Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 128809 - "Reverse" blockers aren't respected
Summary: "Reverse" blockers aren't respected
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Dependencies (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
Keywords: InVCS
: 155634 (view as bug list)
Depends on:
Blocks: 155723 300071 147007
  Show dependency tree
Reported: 2006-04-04 12:39 UTC by Donnie Berkholz (RETIRED)
Modified: 2011-05-22 21:22 UTC (History)
3 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 Donnie Berkholz (RETIRED) gentoo-dev 2006-04-04 12:39:28 UTC
If A blocks B, and A is installed, then B shouldn't be installable. It should be unnecessary to specify blockers in both directions to get an effective block.

genone cited some weird exception where this shouldn't happen when B can't build if A is installed, but A can be installed after the build. But that will result in requiring uninstall/reinstall cycles of A every time there's an upgrade to B, so imho it should be fixed in the package source rather than working around it in portage.

An example use case is with modular and monolithic X. x-modular.eclass blocks monolithic X, but it's still possible to install it on top of modular X. It shouldn't be.
Comment 1 Donnie Berkholz (RETIRED) gentoo-dev 2006-04-04 12:47:03 UTC
Jakub pointed out that this is a subset of a more general problem -- installed packages aren't used in dependency calculations.

*** This bug has been marked as a duplicate of 48195 ***
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-11-19 07:41:20 UTC
*** Bug 155634 has been marked as a duplicate of this bug. ***
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-11-19 07:42:06 UTC
This case has not been fixed in Bug 48195; reopening.
Comment 4 Avuton Olrich 2006-11-19 07:44:53 UTC
#comment 3 was talking about me:

sbh@rocket gmpc-live % sudo emerge gmpc-live gmpc -pv

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] media-sound/gmpc-live-0.1  0 kB [3]
[ebuild  N    ] media-libs/libmpd-0.12.0  0 kB
[ebuild  N    ] media-sound/gmpc-0.13.0  USE="-gnome" 457 kB

Total: 3 packages (2 new, 1 reinstall), Size of downloads: 457 kB
Portage overlays:
 [1] /usr/local/portage-overlays/portage
 [2] /usr/local/portage-overlays/layman/gentopia
 [3] /usr/local/portage-overlays/mpd-portage


Comment 5 Zac Medico gentoo-dev 2006-11-19 14:35:43 UTC
One of the root problems here is that portage only traverses a minimal number of dependencies by default (speeds up dep calculations a little).  This has a few consequences:

1) Deep dependencies are only verified when --deep is enabled.
2) Some operations that don't take the whole depgraph into account can potentially put it into an inconsistent state when viewed as a whole (leading to the one-way blockers problem).
3) Even when whole depgraph is considered, sometimes it ends up in an inconsistent state anyway.  At this point, backtracking is required in order to resolve any inconsistencies that remain (bug 1343 and bug 137562).
Comment 6 Zac Medico gentoo-dev 2006-12-09 16:33:29 UTC
This is implemented in svn r5248 but it is only enabled with the --deep option due to the performance penalty incurred by additional dep_check calls.
Comment 7 Donnie Berkholz (RETIRED) gentoo-dev 2006-12-09 19:07:58 UTC
(In reply to comment #6)
> This is implemented in svn r5248 but it is only enabled with the --deep option
> due to the performance penalty incurred by additional dep_check calls.

So we still can't count on blockers properly working.
Comment 8 Zac Medico gentoo-dev 2006-12-09 19:59:40 UTC
I'll do some profiling and see if I can increase the performance.  I'm not sure how users will react to the reduction in performance.  In my tests, small dependency calculations took an extra 10 or 15 seconds.
Comment 9 Zac Medico gentoo-dev 2006-12-09 20:57:04 UTC
The new reverse-blocker behavior is available when --deep is enabled in 2.1.2_rc3-r1.  In case you're wondering how much the the performance penalty is, it's about the same as a --depclean calculation.  Maybe the performance penalty is acceptable and maybe it's not.  The performance penalty is directly proportional to the number of packages installed.  Hopefully it will be possible to do some significant performance optimizations without too much work...
Comment 10 Zac Medico gentoo-dev 2006-12-10 02:38:28 UTC
In svn r5248:5255 if done a series of optimization and enabled the blocker detection by default since the performance now seems acceptable. :)
Comment 11 Donnie Berkholz (RETIRED) gentoo-dev 2006-12-10 12:22:30 UTC
Thanks Zac!
Comment 12 Zac Medico gentoo-dev 2006-12-10 16:13:08 UTC
This has been released in 2.1.2_rc3-r2.
Comment 13 Carsten Lohrke (RETIRED) gentoo-dev 2006-12-11 06:00:27 UTC
*** Bug 157823 has been marked as a duplicate of this bug. ***
Comment 14 Carsten Lohrke (RETIRED) gentoo-dev 2006-12-11 06:02:19 UTC
This isn't a bug at all. It's a fault of the developer not to block the packages mutually.
Comment 15 Zac Medico gentoo-dev 2006-12-11 09:05:24 UTC
(In reply to comment #14)
> This isn't a bug at all. It's a fault of the developer not to block the
> packages mutually.

That won't work for overlays though, will it?

In the main tree, the requirement to specify each block twice seems like it can be annoying (especially in modular/monolithic relationships).  It's doable, but then we're still left with the overlays issue.  I wonder if there are any others...
Comment 16 Robert Forsman 2007-01-26 21:38:58 UTC
New data point.

I always lag mythtv, delaying upgrading till some friends have checked it out, and then picking a time when I have a few hours to sort out any problems.

I currently have to alter /etc/portage/package.mask on all of my mythfrontends (laptops throughout the house). I decided to experiment with a dependency-only ebuild: bob/bob-mythtv: which encapsulates this logic and lives in my rsynced portage overlay.

DESCRIPTION="specifies the bob-approved version of mythtv"

When I install this and remove media-tv/mythtv from /var/lib/portage/world and remove the masking from /etc/portage/package.mask, emerge --tree -uvDN -p world  (WITH portage-2.1.1-r2!!, not 2.1.2) still suggests

[ebuild     U ] x11-themes/mythtv-themes-0.20 [0.19] 13,851 kB 
[nomerge      ] x11-themes/mythtv-themes-0.19  
[ebuild     U ]  media-tv/mythtv-0.20_p12172 [0.19_p10505] USE="alsa dts%* dvd frontendonly mmx opengl perl%* vorbis (-altivec) -backendonly -crciprec% -dbox2 -debug -dvb -freebox% -hdhomerun% -ieee1394 -ivtv% -jack -joystick -lcd -lirc -xvmc" VIDEO_CARDS="nvidia -i810 -via" 12,108 kB 

masking >=x11-themes/mythtv-themes-0.20 causes it to report

!!! All ebuilds that could satisfy "=x11-themes/mythtv-themes-0.20*" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-themes/mythtv-themes-0.20 (masked by: package.mask)

  crazy.  I have not tested with portage 2.1.2

  Consider this a concrete example for comment #15 .