> -----Original Message----- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core- > boun...@lists.openembedded.org] On Behalf Of Richard Purdie > Sent: Thursday, September 03, 2015 2:39 PM > To: Khem Raj > Cc: Patches and discussions about the oe-core layer; Slater, Joseph; Otavio > Salvador > Subject: Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe > > On Thu, 2015-09-03 at 14:15 -0700, Khem Raj wrote: > > > On Sep 3, 2015, at 1:27 PM, Richard Purdie > > > <richard.pur...@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.ashfi...@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 assumed thats one reason to not include it. I am trying to understand > > reasoning to > > not include busybox. Or is is just because its a poster child for > > litigations. > > The litigation issues surrounding it certainly don't do it any favours, > but the main issue is that if busybox is there, we're not seen as a > "proper/full" linux. > > > > 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). > > > > as we include other alternative providers, they get preference over busybox > > applets > > even if busybox is part of it. > > The problem is some people don't want any busybox. > > > > 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… > > > > PR I see. I was searching for technical reasons. > > Well, its technical but related to the image of the project too. Can > OE-Core today produce a "standard linux desktop" type "full" featured > filesystem? I cannot honestly say it can due to this reason, busybox has > to be there. There are some people who do discount OE because of this. > This isn't new, I remember Marcin amongst others working on this. We're > close, but close doesn't mean we can answer "yes" to the question and I > think it would be nice to be able to do so clearly.
I think if we are trying to allow removing busybox, the functionality needed should be in oe-core. Thus, we pull run-parts out of debianutils (this is now in oe-core, master), pull start-stop-daemon from dpkg (I sent a patch, but I have not seen any action), and we add ifupdown. shadow is there, as is util-linux-blkid. Me? I kind of like busybox, but I also think we should provide images without it. Joe > > Cheers, > > Richard > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
