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.
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 ***
*** Bug 155634 has been marked as a duplicate of this bug. ***
This case has not been fixed in Bug 48195; reopening.
#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 media-sound/gmpc-live DEPEND=">=x11-libs/gtk+-2.4 >=gnome-base/libglade-2.3 dev-perl/XML-Parser media-libs/libmpd-live >dev-util/gob-2 net-misc/curl !media-sound/gmpc" PDEPEND="!media-sound/gmpc" RDEPEND="!media-sound/gmpc"
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).
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.
(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.
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.
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...
In svn r5248:5255 if done a series of optimization and enabled the blocker detection by default since the performance now seems acceptable. :)
Thanks Zac!
This has been released in 2.1.2_rc3-r2.
*** Bug 157823 has been marked as a duplicate of this bug. ***
This isn't a bug at all. It's a fault of the developer not to block the packages mutually.
(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...
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" SLOT="0" KEYWORDS="x86" DEPEND="<media-tv/mythtv-0.20" RDEPEND="!>=media-tv/mythtv-0.20" 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 .
