On Thu, Sep 3, 2015 at 5:24 PM, Khem Raj <[email protected]> wrote: > >> On Sep 3, 2015, at 2:02 PM, Bruce Ashfield <[email protected]> wrote: >> >> On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador >> <[email protected]> wrote: >>> On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie >>> <[email protected]> wrote: >>>> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote: >>>>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <[email protected]> >>>>> 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" -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
