I finally figured out why portage keeps fluctuating between upgrading and downgrading these packages. It seems that every time I upgrade system or world, it isn't the right version. *sigh*
I added '-t' to my emerge and discovered a package that isn't in my keywords file.
daevid edb # emerge -Davut world
These are the packages that I would merge, in reverse order:
Calculating world dependencies ...done!
[nomerge ] media-plugins/gst-plugins-alsa-0.8.7-r1 [nomerge ] media-libs/gst-plugins-0.8.7 +alsa -debug +esd +oss [nomerge ] media-plugins/gst-plugins-vorbis-0.8.5 [ebuild UD] media-libs/gst-plugins-0.8.5-r1 [0.8.7] +alsa -debug +esd
+oss 0 kB
Total size of downloads: 0 kB
My /etc/portage/package.keywords contains
media-libs/gstreamer ~x86 media-libs/gst-plugins ~x86
Adding "media-plugins/gst-plugins-vorbis" to the file made it stop being so obnoxious.
So the real question is, is this a 'bug' or 'feature request' for portage.
It seems it should have warned me somehow that -vorbis- isn't masked, yet
the other packages are.
Masking has nothing to do with it, except by accident, afaik. I had this problem myself, and it seemed to be due to some of the gstreamer plugins being updated, and some not.
The gst-plugins package and the specific gstreamer plugins such as the vorbis plugin are related both to each other and the gstreamer version.
As you see, both gstreamer and the plugins package are available in version 0.8.7, but the vorbis package is only available in version 0.8.5 (before ~masking comes into play), which is linked to the gst-plugins package. The individual plugin and the gst-plugins package must be the same version, but the gst-plugins package also wants to be the same version as gstreamer. This is why the gst-plugins package keeps trying to upgrade, to match the gstreamer version, then downgrade, to match the vorbis plugin version.
Your solution to this is 'correct', since the vorbis plugin is the 'problem'.
I don't see it as a bug, maybe a feature request (although I'd think it's fairly questionable). Vorbis support is, after all, optional, and optional means that you are supposed to be paying attention to how it relates to the main trunk feature. If you're already manually unmasking gstreamer and gstplugins, it seems reasonable that you the user should also manually confirm the status of the optional features you choose and unmask them manually as well.
The only 'issue' I see that might be a bug is gst-plugin's connection to both lower versions of individual plugins, and higher versions of gstreamer that do not support the lower version plugins. But I don't know enough about gstreamer to know if that's "not right" or "an upstream problem" or an ebuild issue. I find it weird, but then again, one should really not be using lower-version plugins with a higher version of gstreamer anyway, so while it may not be "right", one should practically not be encountering this problem anyway (but rather the problem of reduced function while the plugin is unavailable, which does fall under feature request, except that the devs were very good about getting the plugins updated to conform with the gstreamer version within a couple of days, from what I saw).
Is there any further information on b.g.o, such as previously submitted bugs to this effect?
Holly
-- [email protected] mailing list
