From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>,
Joe Slater <jslater@windriver.com>,
Otavio Salvador <otavio.salvador@ossystems.com.br>
Subject: Re: [PATCH 1/2] ifupdown: import recipe
Date: Thu, 03 Sep 2015 22:39:01 +0100 [thread overview]
Message-ID: <1441316341.24871.141.camel@linuxfoundation.org> (raw)
In-Reply-To: <584C7C63-C980-48F9-AFCF-8F18E8C8E442@gmail.com>
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.
Cheers,
Richard
next prev parent reply other threads:[~2015-09-03 21:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-01 21:34 [PATCH 0/2] add ifupdown Joe Slater
2015-09-01 21:34 ` [PATCH 1/2] ifupdown: import recipe Joe Slater
2015-09-02 15:55 ` Otavio Salvador
2015-09-02 19:09 ` Randy MacLeod
2015-09-02 19:23 ` Otavio Salvador
2015-09-03 12:11 ` Richard Purdie
2015-09-03 12:15 ` Otavio Salvador
2015-09-03 12:20 ` Bruce Ashfield
2015-09-03 20:22 ` Khem Raj
2015-09-03 20:27 ` Richard Purdie
2015-09-03 20:32 ` Otavio Salvador
2015-09-03 21:02 ` Bruce Ashfield
2015-09-03 21:24 ` Khem Raj
2015-09-03 21:38 ` Bruce Ashfield
2015-09-03 21:15 ` Khem Raj
2015-09-03 21:39 ` Richard Purdie [this message]
2015-09-04 1:12 ` Slater, Joseph
2015-09-03 21:28 ` Phil Blundell
2015-09-03 21:46 ` Khem Raj
2015-09-03 12:32 ` Jack Mitchell
2015-09-01 21:34 ` [PATCH 2/2] ifupdown: create alternative links Joe Slater
-- strict thread matches above, loose matches on Subject: below --
2015-10-09 12:24 [PATCH 1/2] ifupdown: import recipe Andrew Shadura
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1441316341.24871.141.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=jslater@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio.salvador@ossystems.com.br \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.