Re: [PATCH 1/2] ifupdown: import recipe

["Slater, Joseph" <joe.slater@windriver.com>]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-
> bounces@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.purdie@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@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