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

[Koen Kooi]

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 :)

regards,

Koen