[meta-virtualization] [PATCH] Update the netcat with debian patches to fix some error

Bruce Ashfield bruce.ashfield at gmail.com
Sun Jan 6 07:48:10 PST 2013


On Sun, Jan 6, 2013 at 7:59 AM, David Nyström <david.c.nystrom at gmail.com>wrote:

> On 01/05/2013 07:44 PM, Bruce Ashfield wrote:
>
>> On Sat, Jan 5, 2013 at 9:46 AM, David Nyström <david.nystrom at enea.com
>> >wrote:
>>
>>
>>>
>>> On 01/05/2013 03:26 PM, lei yang wrote:
>>>
>>>  On Sat, Jan 5, 2013 at 5:55 AM, David Nyström <
>>>> david.c.nystrom at gmail.com>
>>>> wrote:
>>>>
>>>>  On 01/05/2013 02:43 PM, lei.yang at windriver.com wrote:
>>>>>
>>>>>
>>>>>> From: Lei Yang <lei.yang at windriver.com>
>>>>>>
>>>>>>  I think we should hold on this merge completely. netcat is already
>> covered
>> by meta-networking, so
>> we should be consolidating patches and support there.
>>
>> If there are any specific meta-virt requirements for netcat, we should
>> either use bbappends (and
>> depend on meta-networking, or use the combo-layer tools to pull the
>> support
>> directly) or better yet
>> get them merged into meta-networking.
>>
>> Cheers,
>>
>> Bruce
>>
>>
> I'm totaly OK with this, as long as its accepted somewhere.
> As Lei states though, we need to document the layer setup in README.
>
>
+1


> However, for future reference, I see no reason why new recipes can't end
> up in meta-virtualization first for a usable working setup, and when
> accepted upstream, they will be removed.
> I suggest we use recipes-external/meta-<**potential-upstream-here>/new-**recipe-name/
> until accepted elsewhere.
>

I don't disagree with this process either, but I wouldn't want it to become
the first choice
of a recipe flow. It creates more churn and work to bounce through a
temporary location
rather than going directly to where things belong.

If we have trouble getting a recipe accepted elsewhere, the choice of
another layer isn't
obvious, or there's a real time pressure, I'd completely agree that this is
the right thing
to do.

It's just that in this case, the flow to meta-networking is fairly obvious
(to me at least)
and there's no time pressure .. so trying to get it into meta-networking
first was a good
idea.

Cheers,

Bruce


>
> Br,
> David
>
>
>>
>> ______________________________**_________________
>> meta-virtualization mailing list
>> meta-virtualization@**yoctoproject.org<meta-virtualization at yoctoproject.org>
>> https://lists.yoctoproject.**org/listinfo/meta-**virtualization<https://lists.yoctoproject.org/listinfo/meta-virtualization>
>>
>>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20130106/a2b4c4e9/attachment.html>


More information about the meta-virtualization mailing list