[OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries

Gary Thomas gary at mlbassoc.com
Fri Feb 12 10:40:56 UTC 2016


On 2016-02-12 09:37, Gary Thomas wrote:
> On 2016-02-12 09:32, Richard Purdie wrote:
>> On Fri, 2016-02-12 at 09:29 +0100, Gary Thomas wrote:
>>> On 2016-02-12 09:17, Richard Purdie wrote:
>>>> On Fri, 2016-02-12 at 04:58 +0100, Gary Thomas wrote:
>>>>> Improve the packaging of the libraries built by this recipe.
>>>>>   These
>>>>> are created using special code in the recipe and the debug (-dbg)
>>>>> packages were not being created.  Adding these packages allow the
>>>>> libraries in question to be debugged using GDB.
>>>>
>>>> This isn't really policy, the policy is one -dbg package per recipe
>>>> and
>>>> that is how the dependency chains and dbg-pkgs in IMAGE_FEATURES
>>>> work
>>>> and so on.
>>>>
>>>> I'm not arguing this is perfect, its not and I would like to see it
>>>> change. It is how it all works today though. Is there a pressing
>>>> reason
>>>> we need to do something different here?
>>>
>>> Without this change, none of the [renamed] libraries generated by
>>> the ffmpeg recipe have debug symbols available.  As is, the recipe
>>> is generating separate -dev packages for each library - how is that
>>> different [policy-wise]?
>>>
>>> Should the -dev and -dbg info for the libraries be bundled into
>>> ffmpeg-dbg and ffmpeg-dev?  Or perhaps the machinations generating
>>> the -dev packages in that recipe are just wrong?
>>
>> There should only be one -dev package too.
>>
>> As you saying the debug symbols are getting placed into the -dev
>> packages? They must be getting placed and hence packaged somewhere?
>
> I'm not sure where they were going before this change.
>
> It does look like this recipe is packaging things incorrectly, at
> least against policy.  I think the biggest thing they were attempting
> to achieve was packaging of static development libraries (*.a) in
> their own packages.  Should all of this just be in ffmpeg-dev?
>
> I could try just disabling their special packaging and see how well
> it works.
>
>

Policy notwithstanding, there are a lot of lib*-dbg* packages generated
by non-lib* recipes, so my solution doesn't seem so out of place to me.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



More information about the Openembedded-core mailing list