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
------------------------------------------------------------
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
