All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Rafael Giani <dv@pseudoterminal.org>
To: "Iorga, Cristian" <cristian.iorga@intel.com>
Cc: "openembedded-devel@lists.openembedded.org"
	<openembedded-devel@lists.openembedded.org>
Subject: Re: Please submit your unindexed layers
Date: Tue, 07 May 2013 12:49:15 +0200	[thread overview]
Message-ID: <5188DC2B.9080909@pseudoterminal.org> (raw)
In-Reply-To: <969F26A8BAB325438E7EB80D3C3134FB1622BB2A@IRSMSX102.ger.corp.intel.com>

On 05/07/2013 09:24 AM, Iorga, Cristian wrote:
> Hello all,
>
> My opinion is that we can directly integrate gstreamer-1.0 into oe-core, as it does not replace gstreamer-0.10.
> I did not test this scenario, so I don't know if it's working, but I will do that and see how it is working.
>
> Regards,
> Cristian
>
> -----Original Message-----
> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> Sent: Thursday, May 02, 2013 5:11 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Carlos Rafael Giani; Burton, Ross; Iorga, Cristian
> Subject: Re: [oe] Please submit your unindexed layers
>
> On Thursday 02 May 2013 15:54:39 Carlos Rafael Giani wrote:
>> While I do have a layer for GStreamer 1.0 , I did not want to add it
>> to the index. My guess was that OE core developers might have been
>> preparing recipes for GStreamer 1.0 for later OE core versions
>> already, so the layer would then eventually be in conflict with OE core.
>>
>> So, should I add it now?
> I guess it depends on how long it will take to integrate these recipes in OE- Core. If it's going to take more than a couple of weeks it's probably fine to add it to the index with a note saying the layer is temporary until the recipes are integrated.
>
> Cristian, Ross - opinions?
>
> Cheers,
> Paul
>

I added support for dylan to meta-gstreamer1.0 . There are a few points 
I'd like to take care of before or during an integration into OE-Core:

* it uses _prepend in various places; I was able to replace all but one 
of them with prefuncs. The remaining one is populate_packages_prepend , 
and I just do not see how this could be turned into a prefunc. (And it 
is necessary to use it, because do_packages_split apparently cannot be 
used anywhere else.)
   I think prefuncs are cleaner, because they do not modify an existing 
function. Also, if the indentation style changes again someday, prefuncs 
cause less problems than _prepend does.

* Empty -glib and -apps packages are generated, which are necessary, 
since the -meta packages depend on them. I think this can be done a bit 
smarter, that is, make the -meta package depend on these only if they 
are not empty.

* gstreamer1.0-omx contains a raspberrypi specific part, which is 
enabled explicitely. If enabled, it makes the package machine specific. 
It can be seen here: 
https://github.com/dv1/meta-gstreamer1.0/blob/master/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc#L28 
what is your opinion about this? (Also, it is currently missing a 
GSTREAMER_1_0_OMX_CORE_NAME setting , which is different for the 
raspberry pi than for bellagio.)

* The recipes make use of PACKAGECONFIG to enable/disable plugins with 
dependencies and some features (like Orc, or LGPL mode in 
gstreamer1.0-libav). I also explicitely disable any packages that were 
either not ported to 1.0 , or have dependencies without any known OE 
recipes in OE-Core or meta-oe . This is best shown in -bad : 
https://github.com/dv1/meta-gstreamer1.0/blob/master/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc#L21
I explicitely disable to make sure plugins do not appear all of a sudden 
if someday recipes for a previously unsupported dependency are added and 
the dependency is built with OE. Unfortuantely, upstream did not add a 
configuration option to disable all plugins with dependencies by 
default. (--with-plugins works only for dependencyless plugins.) I 
thought about patching configure.ac , but that would have to be done for 
all plugin packages (-base/-good/-bad/-ugly) , and seemed like something 
that involves more than a few lines, so I hesitated to do it. I'd like 
to hear your opinion about the way it is done now in the recipe.

* Is it okay to add _git versions of the recipes to oe-core?


  parent reply	other threads:[~2013-05-07 11:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-02 13:27 Please submit your unindexed layers Paul Eggleton
2013-05-02 13:54 ` Carlos Rafael Giani
2013-05-02 14:10   ` Paul Eggleton
     [not found]     ` <969F26A8BAB325438E7EB80D3C3134FB1622BB2A@IRSMSX102.ger.corp.intel.com>
2013-05-07 10:49       ` Carlos Rafael Giani [this message]
2013-05-07 13:53         ` Chris Larson
2013-05-07 14:03         ` Burton, Ross
2013-05-02 14:17   ` Burton, Ross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5188DC2B.9080909@pseudoterminal.org \
    --to=dv@pseudoterminal.org \
    --cc=cristian.iorga@intel.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.