[OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

Bruce Ashfield bruce.ashfield at gmail.com
Thu Sep 3 21:02:04 UTC 2015


On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador
<otavio.salvador at ossystems.com.br> wrote:
> On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
>>> >> To put this another way, I think it is probably reasonable that we
>>> >> should be able to build an image from OE-Core with basic functionality
>>> >> like networking without busybox?
>>> >
>>> > That's what I'd support. If everything you need for the functionality with busy
>>> > box is in oe-core, to me, it doesn't make sense to go outside core to get that
>>> > same functionality without busybox.
>>>
>>> irrespective of this change. I see yet another configuration with this
>>> into OE-core, overall OE-Core should get smaller
>>> and case does not sound convincing to me. You dont want to use busybox
>>> in a fairly large image which has other GPLv2 software in
>>> it. Thats fine but doesnt look like a common usecase to me
>>
>> Nobody mentioned GPLv2, that isn't relevant here.
>>
>> I have heard OE being dismissed since it can't produce an image without
>> busybox in it. The implication is we can't build "big" Linux, only small
>> embedded things. The pieces we need busybox for are tiny and should be
>> easy to replace (like this does).
>>
>> So I can see a fairly compelling argument for OE-Core to be able to
>> generate a busybox free image with standard functionality just from a PR
>> perspective. From what I gather we have people willing to test and
>> maintain it too...
>
> If people were demanding it, it would have been moved for
> meta-networking ages ago, it seems it is not the case.

... or they were just holding it elsewhere, since not everyone has the
time to get things merged to core. In particular if they think it will be
a battle.

>
> So my vote is:
>
>  - move to meta-networking

And what if the use cases don't want/need meta-networking ? We have
the submission and one use case, and one of the reasons it was sent
to core was to keep a finite set of layers and recipes to build such an image.

Joe/Randy ?

It is this sort of thing that forces use of combo layers or the whitelist
classes :)

>  - for 2.1 we see if it goes to core or not

But without criteria for success .. what does that get us ? What is the
case that needs to be made for a move to core in 2.1, that isn't being
made now ?

Yes, I'm playing devil's advocate on this thread .. since I want to see
this sort of thing clearly defined.

Cheers,

Bruce

>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"



More information about the Openembedded-core mailing list