Re: Gstreamer packaging

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-06-29 at 10:55 +0100, Phil Blundell wrote:
> On Wed, 2011-06-29 at 11:33 +0200, Koen Kooi wrote:
> > So the new systems does the following:
> > 
> > * split out each plugin as gst-plugin-<foo>
> > * split out each lib as lib<foo>
> > 
> > So both plugins and libraries have a stable package name (barring
> plugin renames, e.g. flvdemux -> flv). Package feeds and upgrades
> finally work as expected
> 
> Agreed, I think this is about the only reasonable thing to do.  The way
> that the gstreamer folks bundle up their plugins for distribution, and
> particularly the semi-arbitrary split between -base, -good and -bad, is
> not especially helpful for consumers of those packages.
>
> In the past I have been strongly tempted to just stick all the plugins
> (with the possible exception of -ugly, which might require a bit of
> ENTERPRISE_DISTRO care) into a single recipe so that at least you always
> know which recipe needs building to get a given plugin.  That would
> obviously lead to more build time but I think it is probably a good
> tradeoff in this situation.  In an ideal world it would be nice for all
> the plugins to be packaged independently a la Xorg, but I have no idea
> whether the gstreamer folks would be receptive to that idea.

Let me quickly recap the problem. Its perfectly reasonable for a recipe
to want to depend on "gst-plugin-<foo>".

The trouble is that bitbake is left pretty much totally clueless when
something says it would like to have "gst-plugin-<foo>" and multiple
things provide it.

Obviously you can make the recipe depend on good+bad+ugly but its less
than ideal for build time reasons (esp. when considering dependencies)
but also the reason that good/bad/ugly exist in the first place which is
licensing. If the recipe always has to depend on good+bad+ugly, it
becomes rather tricky to disable ugly and work out whether the resulting
configuration can build. Companies interested in license compliance do
have a strong need to be able to do this.

Its for the latter reason that OE-Core has kept ${PN} in the plugin
names at present since deterministic builds are kind of nice.

> > OE .dev has a slightly different approach where you manually go
> > through deploy and see what got generated by who and plug that into
> > PROVIDES. I'm not a big fan of that, but it eliminates those scary
> > messages.
> 
> I guess that does also work, but I didn't like the patch when it first
> went into .dev and I am still not very fond of it.

It would at least ensure deterministic builds but I share your lack of
fondness.

A recipe per plugin would certainly start to look attractive and it
might be worth talking to the gstreamer people...

Cheers,

Richard