Re: RFC: gstreamer 1.0 recipes

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Monday 08 April 2013 12:47:51 Koen Kooi wrote:
> Op 8 apr. 2013, om 11:35 heeft "Burton, Ross" <ross.burton@intel.com> het 
volgende geschreven:
> > On 8 April 2013 08:57, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >> I've been meaning to ask the same questions, since I need both orc and
> >> external libav to make gstreamer  (0.10, but still) useable on my
> >> platforms. I came up with the following ideas:
> >> 
> >> 1) Make every external dep a PACKAGECONFIG option in OE-core gstreamer
> >> 2) Add bbappends with extra PACKAGECONFIG options for gstreamer in the
> >> layer that has the external dep 3) add bbappens in the DISTRO layer that
> >> enables extra external dependencies.
> >> 
> >> Angstrom is currently using 3) and I absolutely hate it. 2) is scales a
> >> lot better, but apparently is verboten judging from the patches sent
> >> that remove the qt bbappends that do the same. Which leaves 1), which
> >> will cause problems for most users, since they will spot the
> >> PACKAGECONFIG options but not bother to read the comments saying they
> >> need to enable extra layers.
> >> 
> >> I favour 1) since that has all the knowledge in a single place, looked
> >> after by the OE gst maintainer (which we don't have yet, but still).> 
> > (1) definitely needs to happen in my opinion  I'm not a massive fan of
> > (2) in general as it leads to stuff changing simply by adding a layer
> > - you may pull in meta-oe for some other packages but suddenly the
> > GStreamer package is pulling in more dependencies.  I guess for things
> > like GStreamer where the dependencies are generally isolated into
> > separate packages this is less of an issue though.
> 
> Same thing is true to Qt, the *sql plugins are all subpackages. I realize 2)
> is unclear on wether the extra PACKAGECONFIG default to on or off.
> 
> Both Qt and gstreamer have nice automated packaging of their plugins, so
> bbappends are generally safe to use, but both of them also have configure
> options that enable/disable complete libraries (e.g. QtOpenGL) that might
> trigger missing symbols in other libraries in Qt/gstreamer (again,
> QtOpenGL).
> 
> So were do we as OE(-core) community draw the line for bbappends in layers?

Let's be clear, we're talking about bbappends in meta-oe and other software 
layers.

> For Qt it seems to be at "No bbappends allowed", but should we consider
> drawing it at "safe plugins only"? For generic layers like the ones in
> meta-oe I sure as hell don't want the "unsafe libraries" bbappends.

Apart from not having its configuration changed, given how huge Qt is I want it 
to *not* be rebuilt just as a consequence of adding meta-oe to my 
bblayers.conf. (Of course I can't have that yet because the bbappends have to 
at least have PRINC set in them still, but as soon as PV gets bumped...).

Honestly I think solution 1 is fine; in fact we already have that for some 
recipes. We would have had PACKAGECONFIG for these Qt SQL plugins except that 
as I've mentioned numbers of times, PACKAGECONFIG can't work for these three-
state options. One alternative would be to auto-add DEPENDS / CFLAGS based on 
QT_SQL_DRIVER_FLAGS.

Returning to the original topic, a case could be made for just bringing orc 
and libav into OE-Core. That's not going to work for every situation but we 
ought to be looking at these kind of things on a case-by-case basis.
 
Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre