Re: [gentoo-devhelp] What's the proper way to depend on gstreamer?

[Nathan Phillip Brink]

On Mon, May 04, 2015 at 08:10:12AM +0300, Nikos Chantziaras wrote:
> Currently, I have an ebuild for a project of mine that needs gstreamer
> (1.x) to play videos. I have these deps:
>
>    RDEPEND="(media-libs/gst-plugins-good:1.0
>            media-plugins/gst-plugins-libav)"
>
>    DEPEND="media-libs/gst-plugins-base:1.0"
>
> During building, some headers from plugins-base are needed and libraries
> from that are linked directly, that's why that's in DEPEND and the
> others in RDEPEND.
>
> However, if the system has no gstreamer installation at all currently,
> then this will not install stuff like media-plugins/gst-plugins-pulse,
> which might be needed on a PulseAudio-enabled system.
>
> Should I also depend on media-plugins/gst-plugins-meta in order to make
> sure that this gets installed?
>
> Note that the project in question doesn't care at all about this
> low-level stuff. PulseAudio or ALSA for example doesn't matter. All the
> project knows about is the gstreamer API, plugins-good and plugins-base.
>
> Even plugins-libav is not used directly, but is a dep simply because
> that's the only way to get gstreamer to *hopefully* play all video
> formats correctly (assuming the user hasn't crippled libav by disabling
> USE flags in media-video/libav.) I wouldn't know how to prevent that
> from happening in the first place; for example, how do I make sure the
> ebuild can request all deps in a way that makes playback of H.264 or VC8
> or Theora video possible. Again through plugins-meta? That lacks an h264
> USE flag though (but does have an "ffmpeg" USE flag which pulls
> plugins-libav as a dep.)

I would just look for an example in the tree that does something with
gstreamer. net-im/pidgin-2.10.11 has the following in RDEPEND (which
is included in DEPEND). For something like pidgin, where it is known
in advance that particular codecs are needed to generally get voice
chat support with popular IM networks, it makes sense to force at
least support for those codecs.

    gstreamer? ( =media-libs/gstreamer-0.10*
        =media-libs/gst-plugins-good-0.10*
        net-libs/farstream:0.1
        media-plugins/gst-plugins-meta:0.10
        media-plugins/gst-plugins-gconf:0.10 )

Mozillaish ebuilds (at least FireFox and SeaMonkey, through
mozconfig-v5.36.eclass) have in RDEPEND (which is fully included into
DEPEND). It looks like they force the libav plugin, probably it gets
support for the popular <video/>/<audio/> stuff through that?

    gstreamer? (
        >=media-libs/gstreamer-1.2.3:1.0
        >=media-libs/gst-plugins-base-1.2.3:1.0
        >=media-libs/gst-plugins-good-1.2.3:1.0
        >=media-plugins/gst-plugins-libav-1.1.0_pre20130128-r1:1.0
    )

If your project can only be useful to users if libav and plugins-good
is present, then the in-tree precedents I found suggest you should
just go ahead and depend on the codecs. I do like how you are doing
better than the tree by only putting the codecs in RDEPEND, I think in
rare cases that might give portage the wiggle-room it needs to handle
dependencies during world updates, though I’m not sure. It’s being
“more correct” and informative, at least ;-). However, be sure that
you at least have gst-plugins-base in RDEPEND—even though it is
implicitly there through an indirect dependency through
gst-plugins-good and gst-plugins-libav, your project *does* directly
use gst-plugins-base and should inform portage that it needs to be
kept installed.

However, if your project could conceivably be useful with a more
minimal set of gstreamer codecs, it might be nice to give the user
more power by putting the default set of codecs behind a
default-enabled useflag. Something like:

    IUSE="+gstreamer-codecs"
    
    COMMON_DEPEND="media-libs/gst-plugins-base:1.0"
    RDEPEND="${COMMON_DEPEND}
        gstreamer-codecs? ( media-libs/gst-plugins-good:1.0
            media-plugins/gst-plugins-libav )"
    DEPEND="${COMMON_DEPEND}"

This would enable power users to choose what gstreamer codecs to
build, especially if they are targeting something like an embedded
system.

Hopefully I said something wrong that will trigger someone else to
provide actual useful information ;-).

-- 
binki

Look out for missing or extraneous apostrophes!