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