Re: [RFC 1/2] gstreamer: sync packaging with OE .dev

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

On Fri, 2011-09-16 at 12:06 +0100, Phil Blundell wrote:
> On Fri, 2011-09-16 at 12:00 +0100, Richard Purdie wrote:
> > On Fri, 2011-09-16 at 12:19 +0200, Martin Jansa wrote:
> > > On Fri, Sep 16, 2011 at 11:09:49AM +0100, Richard Purdie wrote:
> > > > On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote:
> > > > > some text here
> > > > 
> > > > It took all my restraint to not just reply with:
> > > > """
> > > > NAK
> > > > 
> > > > <insert reason for NAK here, I can't be bothered to type it>
> > > > """
> > > > 
> > > > We've been around in a few circles with this. The problem is that if we
> > > > apply this patch we have no clue which gst-plugin from the good, the bad
> > > > and the ugly provides something you're after to include in an image.
> > > > This results in bitbake being pretty clueless about whether a given
> > > > build will succeed or not. In general I'm not a fan of having
> > > > non-deterministic builds as they tend to annoy users.
> > > > 
> > > > If this position isn't acceptable then we'll probably have to move to a
> > > > situation where we list which plugins each of the packages builds and
> > > > drop the dyanmic provides. That is a maintenance pain and I don't take
> > > > that step lightly but I don't see any other options. I'm open to
> > > > suggestions though.
> > > 
> > > Something like:
> > > http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031739.html
> > > http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031740.html
> > > ?
> > 
> > Yes. I'd probably have written separate .inc files to simplify the
> > script but I'm thinking along those lines. I'm not particularly happy
> > about it but I don't see many other options.
> 
> Last time this issue came up we talked about simply merging the -good,
> -bad and -base plugins into a single recipe (since there appears to be
> no very compelling reason to keep them separate) and just leaving the
> -ugly ones on their own.  That still seems to me as though it is the
> best way of making a lot of that complexity just go away.  Then
> something like Martin's script could be used to figure out the (mostly
> static, with a bit of luck) split between -ugly and the rest.

When put like this it doesn't sound so attractive since you need the
scripts for ugly anyway. Keeping them separate does actually help build
time at least since the plugins are one of the last things to get built
and if merged, you also have to merge all the dependencies, compounding
the build time.

Cheers,

Richard