gst-plugins has a weird self-circular dependency: * media-libs/gst-plugins (=0.8.11) Build dependencies: ( >=media-libs/gstreamer-0.8.11 >=gnome-base/gconf-2 !alpha? ( !arm? ( !ia64? ( !mips? ( !ppc64? ( >=dev-libs/liboil-0.3.0 ) ) ) ) ) >=sys-devel/gettext-0.11.5 >=dev-util/pkgconfig-0.9 !bootstrap? ( sys-devel/patch ) !bootstrap? ( sys-devel/patch ) sys-devel/gnuconfig sys-devel/automake sys-devel/autoconf sys-devel/libtool =media-libs/gst-plugins-0.8.11* >=sys-apps/sed-4 >=sys-apps/sed-4 !bootstrap? ( sys-devel/patch ) !bootstrap? ( sys-devel/patch ) ) Runtime dependencies: ( >=media-libs/gstreamer-0.8.11 >=gnome-base/gconf-2 !alpha? ( !arm? ( !ia64? ( !mips? ( !ppc64? ( >=dev-libs/liboil-0.3.0 ) ) ) ) ) =media-libs/gst-plugins-0.8.11* ) Post dependencies: ( oss? ( >=media-plugins/gst-plugins-oss-0.8.11 ) alsa? ( >=media-plugins/gst-plugins-alsa-0.8.11 ) esd? ( >=media-plugins/gst-plugins-esd-0.8.11 ) ) Looks like the (R)DEPEND logic in the eclass is broken.
I already noted this on Bug 104210, which has been erroneously closed again. gst-plugins.eclass <snip> MY_P=gst-plugins-${PV} RDEPEND="=media-libs/${MY_P}*" </snip> @compnerd: Any version bump cannot fix this thing, portage won't handle the above. If this weird stuff can't work with RDEPEND=">=media-libs/${MY_P}*" for whatever reason, then you are stuck with merging all the ebuilds into one "meta" ebuild and using a bunch of use flags to install the individual plugins. You cannot simply bump/upgrade one and leave the others anyway, due to the above deps - so there's no reason for those individual ebuilds to exist.
It does not depend on itself, plugins that use the eclass like the ones in media-plugins/gst-plugins-* depend on the same version as itself of media-libs/gst-plugins As compnerd has said: to bump plugins (in the 0.8 series) you have to bump them all at same time. Same goes with stabilising them on an arch, they all need to be done at same time.
(In reply to comment #2) I'd suggest that you actually run emerge with --debug sometimes to watch the fun your eclasses produce. The eclasses result in broken circular dependencies, users are complaining about upgrade/downgrade cycles over and over again, and the bugs are getting marked INVALID/FIXED over and over again, but there's no fix actually. 1/ - media-libs/gst-plugins inherits gst-plugins.eclass. - that eclass has MY_P=gst-plugins-${PV} (R)DEPEND="=media-libs/${MY_P}*" - media-libs/gst-plugins therefore (R)DEPENDs on itself - on every version bump, this whole thing produces stuff like media-libs/gst-plugin-0.8.11 (R)DEPENDs on media-libs/gst-plugin-0.8.10, because the dependency is circular and portage doesn't handle that. So, one time you run emerge -uD world, all the stuff upgrades, the second time it downgrades, yay that's fun. 2/ gst-plugins-base.eclass sets (R)DEPEND like MY_PN=gst-plugins-base MY_P=${MY_PN}-${PV} RDEPEND="=media-libs/${MY_P}" media-libs/gst-plugins-base again (R)DEPENDs on itself. - on every version bump, this whole thing produces stuff like media-libs/gst-plugins-base-0.10.1 (R)DEPENDs on media-libs/gst-plugins-base-0.10.0. So, one time you run emerge -uD world, the stuff upgrades, the second time it downgrades, more fun. The above applies to gst-plugins-{ugly,good,bad} eclasses equally. You *are* producing circular deps that break the deptree, fix it finally.
ok after debugging, found the circular dep and have now fixed in cvs thanks jakub