On 5/30/13 11:13 AM, Phil Blundell wrote:
On Thu, 2013-05-30 at 10:49 -0500, Mark Hatle wrote:
It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should
really be in one of the other meta-openembedded layers (or even other project
layers). But my customers are not willing to bring in 413 packages just for '1'
package they might need out of the set.
(Similarly, we don't just "bring in" meta-openembedded either.. we break out the
layers so only the ones we're willing to support, and our customers need are
provided to them.) There is no such thing as an "unsupported" package when you
are a commercial vendor.
I'm not entirely sure what you mean by "bring in" in this context or
what the underlying rationale for your reluctance is. But some general
comments:
Support and testing.. if the recipe is there we have to support it, if we don't
ship it to our customers -- they are free to source it themselves, but it's
clear that we didn't test and don't support it.
We provide it, customers expect us to support it. We're not willing to support
meta-oe due to the number of recipes in it. oe-core, meta-yocto,
meta-networking, meta-selinux, meta-webserver, and others we do use, test and
provide to our customer.
It's entirely possible to have a copy of meta-oe on hand and only
include a subset of the recipes in the parse. You can do that either by
adding the layer and then BBMASKing out everything you don't want, or by
not adding the layer as such but just admit individual recipes by adding
them to BBFILES specifically. Either of those approaches would avoid
the risk of accidentally introducing dependencies on recipes from
meta-oe without realising that this is what you are doing.
Also, I think the toxicity of meta-oe nowadays is much less than it used
to be (thanks mostly to excellent work by Paul in cleaning up
I agree, it's significantly better now. I do use meta-oe from time to time on
personal projects...
the .bbappends and overlapping recipes) and, as far as I know, the act
of including meta-oe in your layer list no longer leads to the sort of
random changes to recipe versions and behaviour that you might have
gotten burned by in the past. So if your previous experience is from
some time ago then you might want to give it another try.
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
