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

[Bruce Ashfield]

On Thu, Sep 3, 2015 at 5:24 PM, Khem Raj <raj.khem at gmail.com> wrote:
>
>> 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.

Agreed. No arguments there .. and hopefully we can also finally break the layers
up into smaller parts / separate repos.

I've had the issue that I can't just update meta-networking .. I get everything.
I can help with quality in layers that I use (which I do), but when
versions change
underneath you (and you have a specific requirement), there's little that can
be done ... except copy and pin.

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

Agreed.


Bruce




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