Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 446251

Summary: media-plugins/gst-plugins-dts and others shouldn't depend on media-libs/gst-plugins-bad
Product: Gentoo Linux Reporter: Maxim Kammerer <mk>
Component: New packagesAssignee: GStreamer package maintainers <gstreamer>
Status: UNCONFIRMED ---    
Severity: normal CC: eva, tomwij
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Maxim Kammerer 2012-12-06 13:38:10 UTC
Copied from gentoo-dev:

After the commit 3 days ago all kinds of plugins suddenly depend
on gst-plugins-bad. E.g.: gst-plugins-{dts,faad,libmms,resindvd,xvid}.
Is gst-plugins-bad eclass the wrong one to inherit in their case?

Also, vp8 plugin both inherits from the eclass, and has an explicit
dependency on media-libs/gst-plugins-bad — perhaps one or the other
should be removed.
Comment 1 Gilles Dartiguelongue gentoo-dev 2012-12-06 23:05:28 UTC
afaict these plugins are from bad with the new eclasses all plugins require their base pack to be built. This might not always be necessary but this is more pratical for a couple of reasons like not repeating the dependency in tens of ebuilds but not in a few.

Latest 0.10 and 1.0 slot ebuilds should have no direct dependencies on media-libs/gst-plugins-{base,good,bad,ugly} because this is already taken care of by the eclass. Older ones (stable) have been mostly left as untouched as possible to avoid any unintended breakage.
Comment 2 Maxim Kammerer 2012-12-06 23:19:00 UTC
(In reply to comment #1)
> afaict these plugins are from bad

No, they do not require anything from gst-plugins-bad. The dependencies of these packages changed as a result of the commit, and now include gst-plugins-bad.

> with the new eclasses all plugins require
> their base pack to be built. This might not always be necessary but this is
> more pratical for a couple of reasons like not repeating the dependency in
> tens of ebuilds but not in a few.

What is a base pack, gst-plugins-base? Why do they inherit from gst-plugins-bad then?

> Latest 0.10 and 1.0 slot ebuilds should have no direct dependencies on
> media-libs/gst-plugins-{base,good,bad,ugly} because this is already taken
> care of by the eclass. Older ones (stable) have been mostly left as
> untouched as possible to avoid any unintended breakage.

The ebuilds should still inherit from the correct eclass. It seems that gst-plugins-{dts,faad,libmms,resindvd,xvid} should inherit from gst-plugins-base, not gst-plugins-bad.
Comment 3 Maxim Kammerer 2012-12-06 23:28:36 UTC
I think I see the problem now. You have made the assumption that a plugin whose sources are in gst-plugins-bad should also depend on gst-plugins-bad. This is incorrect:

GST_ORG_MODULE="gst-plugins-bad"
(gst-plugins-bad.eclass)

^^
this is wrong.
Comment 4 Maxim Kammerer 2012-12-06 23:35:51 UTC
Same with good and ugly. Previous {good,bad,ugly} eclasses only depended on gst-plugins-base. You then added GST_ORG_MODULE, and gst-plugins10 now adds a dependency on GST_ORG_MODULE. This is plain wrong.
Comment 5 Maxim Kammerer 2012-12-07 00:54:13 UTC
I did some grepping. Packages in media-plugins explicitly depending on something other than gst-plugins-base:

gst-plugins-mad-0.10.18 (good)
gst-plugins-ladspa-0.10.22 (bad -> signalprocessor)
gst-plugins-rtmp-0.10.22 (bad -> basevideo)
gst-plugins-schroedinger-0.10.22 (bad -> basevideo)
gst-plugins-vp8-0.10.22 (bad -> basevideo)

Non-nextgen packages that do not have explicit dependencies on gst-plugins-base (all others do):

gst-plugins-alsa (meta)
gst-plugins-cdparanoia
gst-plugins-gio
gst-plugins-gnomevfs
gst-plugins-libvisual (meta)
gst-plugins-ogg (meta)
gst-plugins-pango
gst-plugins-theora (meta)
gst-plugins-vorbis (meta)
gst-plugins-x (meta)
gst-plugins-xvideo (meta)

In addition, there is gst-plugins-meta, which encodes extra dependencies that should really be per-package. It unconditionally depends on "base" and "good", and I marked the packages above that meta can pull as (meta). In addition, meta depends on "bad" for gst-plugins-dvb, and on ugly for gst-plugins-mad and an assortment of dvd-related plugins.

Hope this helps.
Comment 6 Gilles Dartiguelongue gentoo-dev 2012-12-07 08:13:35 UTC
If you read my reply, that is what I said:

> all plugins require their base pack to be built

this means that any plugin from gst-plugins-good will depend on gst-plugins-good, same for the others. You are correct that this is a change in dependencies however this greatly simplifies plugins management as you can be sure that everything that is required to build the plugin is already pulled in by the pack.

@herd, simplifying maintenance was one of the primary objectives of this eclass rewrite so what do you say about this ?

> The ebuilds should still inherit from the correct eclass. It seems that
> gst-plugins-{dts,faad,libmms,resindvd,xvid} should inherit from 
> gst-plugins-base, not gst-plugins-bad.

No, the eclass must correspond to the pack the plugins are extracted from.

> Non-nextgen packages that do not have explicit dependencies on 
> gst-plugins-base (all others do):

that's because the base pack already do so it is not necessary to repeat that in all ebuilds.
Comment 7 Maxim Kammerer 2012-12-07 08:36:37 UTC
(In reply to comment #6)
> this means that any plugin from gst-plugins-good will depend on
> gst-plugins-good, same for the others. You are correct that this is a change
> in dependencies however this greatly simplifies plugins management as you
> can be sure that everything that is required to build the plugin is already
> pulled in by the pack.

This is the exact equivalent to saying that udev should be installed with systemd because they are packaged together. Many people use Gentoo because they object to such reasoning. It has nothing to do with simplifying maintenance -- you could have designed the eclasses to separate the pack where the plugin resides from the pack on which the plugin depends, using one more variable.

The statistics I brought above show that only 7-8 plugins depend on "bad" or "ugly", out of 24 that inherit "bad", and 9 that inherit "ugly". Those are not small packs - "bad" takes 2.7M disk space, for instance. I don't see why everyone should be forced to install it, especially since from the popular plugins, it is only actually required by vp8. If anything, I would make a separate package for libgstbasevideo, and depend on that.
Comment 8 Mart Raudsepp gentoo-dev 2012-12-09 05:36:59 UTC
I don't know about 1.0, but in 0.10 we only needed to depend on the relevant media-libs/ package if it used any of the helper libraries (which we also needed to sed about in the eclass to look from system version for splits), and this was trivial to see from the relevant {sys,ext}/${GST_PLUGINS_BUILD_DIR}/Makefile.am and on bumps I just checked over any changes to Makefile.am's in the tarball in addition to configure.ac changes and that's it.
In the long-run all the helper libs in gst-plugins-bad tarball all become good enough quality to be in gst-plugins-base and no -bad splits would need media-libs/gst-plugins-bad.