The basic problem here is a difference in the RDEPENDs between util-linux-2.12r-r8 and util-linux-2.13-r2, in particular for the amd64, mips, ppc, ppc64, and sparc architectures. For those architectures, the 2.12r-r8 ebuild depends on setarch. For all architectures, the 2.13-r2 ebuild depends on *not* having setarch. So if one has util-linux-2.12r-r8 installed and tries to upgrade, a blocker message comes up, and it's not obvious to the user that setarch can be safely unmerged to solve the problem. I'm not sure the best way to inform the user of this, but something should probably be done.
Maybe the user should just read the message on handling blockers which portage spits out and move on.
While that does say how to fix the problem (to whit, unmerge setarch and then update to util-linux-2.13-r2), it's not clear without reading the ebuilds for both versions of util-linux what's going on. A naive user might not feel comfortable unmerging important-sounding packages like "sys-apps/setarch". This isn't like merging slocate and finding that rlocate blocks; this is upgrading a package and finding two apparently-essential packages which don't obviously provide the same functionality to block. I mean, maybe even just adding a note in the changelog of util-linux to say "util-linux-2.13 and above include setarch functionality, feel free to remove that package"? I'll admit it didn't take much looking around to figure out what was going on, but I could imagine someone getting confused by this.
See http://www.gentoo.org/proj/en/glep/glep-0042.html (not implemented in portage yet). Anyway, users generally not grokking blockers is seriously not a bug. If there's a blocker somewhere, they are there for a reason (collisions, breakage) and not to annoy users.
*** Bug 205464 has been marked as a duplicate of this bug. ***
I'm aware that there are reasons for blockers, and those are important. I just wonder if there's a way to inform users of these reasons. Maybe something like ewarn or einfo which comes up in the event of blockers? I'm really not looking for a change in the way that Portage installs packages, just how it informs users when a problem prevents it from doing so. I guess that's beyond the scope of this bug report, though.
No, you can't get any ewarn for blockers, you can't even emerge anything until you resolve the blockers obviously. Once again, move to GLEP42, nothing to be fixed here.
*** Bug 207077 has been marked as a duplicate of this bug. ***
