[OE-core] [PATCH 0/4]Add FUSE: File system in Userspace

[Philip Balister]

On 05/30/2013 12:18 PM, Mark Hatle wrote:
> 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.

Does this mean we should look at splitting meta-oe into more layers? Or
is this issue unique to Wind River?

At some point, the layer dependencies get out of hand.

Philip

> 
>> 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.
>>
>>
> 
>