A world update gave me audacious 2.2_beta1 along with its plugins. As it gave me some trouble, I tried to downgrade to 2.1 using a simple emerge =media-sound/audacious-2.1 which gave me a lot of file collisions with media-plugins/audacious-plugins-2.2_beta1, all of them within /usr/share/audacious/Skins. Even when I tried to downgrade both audacious and audacious-plugins at the same time, portage always wanted to emerge audacious first and audacious-plugins second, giving the same collisions. A workaround is unmerging audacious-plugins before downgrading audacious itself.
Blockers would stop you from being able to downgrade correctly at all. Portages ability to handle P(ost)Depends is limited. This is not an audacious bug.
(In reply to comment #1) > Blockers would stop you from being able to downgrade correctly at all. This is wrong, at least for portage 2.2_rc46: # emerge -p =media-sound/audacious-2.1 =media-plugins/audacious-plugins-2.1-r1 These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild UD] media-sound/audacious-2.1 [2.2_beta1] [ebuild UD] media-plugins/audacious-plugins-2.1-r1 [2.2_beta1] USE="musepack%* wma%* -pulseaudio%" [blocks b ] >=media-plugins/audacious-plugins-2.2_beta1 (">=media-plugins/audacious-plugins-2.2_beta1" is blocking media-sound/audacious-2.1) The last line is a weak block which portage can resolve. You recognize it by the small b, and in the terminal window, by its dark blue color instead of the bright red of an unresolvable block. And of course by the fact that without the -p the downgrade does start. I tried it, and it really does merge cleanly. To achieve this, I had added the following lines to the ebuilds: media-sound/audacious-2.1.ebuild: RDEPEND="${RDEPEND} !>=media-plugins/audacious-plugins-2.2_beta1" media-plugins/audacious-plugins-2.2_beta1.ebuild: RDEPEND="${RDEPEND} !<media-sound/audacious-2.2_beta1" Even if older portage versions were to deal with this issue incorrectly, your statement is wrong. As most users have FEATURES=protect-owned, they will be unable to merge the package in any case, unless they unmerge the plugins first. So in the current setup, they compile stuff, get some error message which might frighten them, and then probably will compile things over again because they don't know how to just merge a package that has already been compiled. With the blockers in place, they would be told up front that what they attempt won't work this way, and avoid compiling stuff they won't be able to merge. Given the alternative, this is clearly the way I'd prefer. > Portages ability to handle P(ost)Depends is limited. The blocker should be an RDEPEND, not a PDEPEND! Of course, not in the part of the RDEPEND which gets included in DEPEND as well, which is the reason I put my blockers in separate lines, after the inclusion of RDEPEND into DEPEND. > This is not an audacious bug. I still believe it is. Did I convince you, or do you still doubt?
I'm going to resolve this as fixed since I don't believe it's valid anymore.
