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

[Khem Raj]

> On Sep 3, 2015, at 2:02 PM, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
> 
> 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.

thats how we bloated oe-classic. Oh people might need it because I need it therefore slam it in
I have written a packagegroup to replace busybox but I never thought it was so core.

> 
>> 
>> 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 :)

You can also help in making those layers meet the quality criteria you need instead of being
pick what I need throw the rest out approach.

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

if its required by more than 1 distro. Is duplicated in other layers because the layer it resides in
is not used by a distro. It replaces a core functionality in OE-Core. It has to be a building block and not a leaf package e.g. These Would be some of things that may be thought of.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150903/cc761e4c/attachment-0002.sig>