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.
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.
(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.
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.
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.
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.
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.
(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.
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.
Current version splits all depend on their main package for practical needs - they need all the main package core dependencies, as all meson.build is checked and thus also the base dependencies that can be changing around a lot. Therefore it doesn't give much benefit to try to avoid vs maintenance burden. The only thing you could really be avoiding is a rather tiny gst-plugins-ugly (realmedia, dvdsub, asf, dvdlpcmdec) and a very typically needed gst-plugins-bad. To really "fix" it, we'd have to apply more meson hacks to get the splits to not recurse into gst-libs/ and gst/ at all, deal with the probable fallout from that, probably sed out a bunch of more things from the toplevel meson.build and so on, and then in the eclass cite the remaining common deps per-suite. Just not worth it for this.
