Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Phil Blundell <philb@gnu.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Subject: Re: [RFC 1/2] gstreamer: sync packaging with OE .dev
Date: Fri, 16 Sep 2011 12:06:20 +0100	[thread overview]
Message-ID: <1316171181.3510.23.camel@phil-desktop> (raw)
In-Reply-To: <1316170848.25993.71.camel@ted>

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.

p.





  reply	other threads:[~2011-09-16 11:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-16  8:20 [RFC 1/2] gstreamer: sync packaging with OE .dev Koen Kooi
2011-09-16  8:20 ` [RFC 2/2] gst-meta-base: adjust plugin names after gstreamer packaging changes Koen Kooi
2011-09-16 10:09 ` [RFC 1/2] gstreamer: sync packaging with OE .dev Richard Purdie
2011-09-16 10:19   ` Martin Jansa
2011-09-16 11:00     ` Richard Purdie
2011-09-16 11:06       ` Phil Blundell [this message]
2011-09-16 13:38         ` Richard Purdie
2011-09-22 11:32           ` Koen Kooi
2011-09-26 18:38             ` Richard Purdie

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=1316171181.3510.23.camel@phil-desktop \
    --to=philb@gnu.org \
    --cc=koen@dominion.thruhere.net \
    --cc=openembedded-core@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox