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

[Richard Purdie]

On Thu, 2011-09-22 at 13:32 +0200, Koen Kooi wrote:
> Op 16 sep 2011, om 15:38 heeft Richard Purdie het volgende geschreven:
> 
> > 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.
> 
> If someone can tell me which solution is preferred I can start working  
> on patches :)

I'm preferring the script generating the list of provides for the
gstreamer recipe...

Cheers,

Richard