From: Mark Hatle <mark.hatle@windriver.com>
To: Phil Blundell <pb@pbcl.net>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/4]Add FUSE: File system in Userspace
Date: Thu, 30 May 2013 11:18:32 -0500 [thread overview]
Message-ID: <51A77BD8.8020302@windriver.com> (raw)
In-Reply-To: <1369930392.8846.58.camel@phil-desktop.brightsign>
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.
>
>
next prev parent reply other threads:[~2013-05-30 16:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 9:01 [PATCH 0/4]Add FUSE: File system in Userspace Hongxu Jia
2013-05-30 9:01 ` [PATCH 1/4] fuse: import recipe from meta-oe Hongxu Jia
2013-05-30 9:01 ` [PATCH 2/4] ntfs-3g-ntfsprogs:import and update " Hongxu Jia
2013-05-30 9:01 ` [PATCH 3/4] fuse-exfat: add version 1.0.1 Hongxu Jia
2013-05-30 9:01 ` [PATCH 4/4] exfat-utils: " Hongxu Jia
2013-05-30 9:18 ` [PATCH 0/4]Add FUSE: File system in Userspace Jack Mitchell
2013-05-30 10:38 ` Paul Eggleton
2013-05-30 12:17 ` Mark Hatle
2013-05-30 12:58 ` Philip Balister
2013-05-30 15:49 ` Mark Hatle
2013-05-30 16:13 ` Phil Blundell
2013-05-30 16:18 ` Mark Hatle [this message]
2013-06-03 11:20 ` Philip Balister
2013-06-03 14:22 ` Mark Hatle
2013-05-30 16:56 ` Khem Raj
2013-05-30 16:59 ` Mark Hatle
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=51A77BD8.8020302@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=pb@pbcl.net \
/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