* Re: [PATCH 1/2] ifupdown: import recipe
@ 2015-10-09 12:24 Andrew Shadura
0 siblings, 0 replies; 20+ messages in thread
From: Andrew Shadura @ 2015-10-09 12:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Joe Slater
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
Hi,
I just wanted to comment on this patch pulled with the recipe:
> +From 74152ac74a3e1ea0f3be292aa1eeca5ad1fe69c0 Mon Sep 17 00:00:00 2001
> +From: Paul Gortmaker <paul.gortmaker@windriver.com>
> +Date: Wed, 6 Aug 2014 15:12:11 -0400
> +Subject: [PATCH 2/2] inet[6].defn: fix inverted checks for loopback
I have already commented on this patch when I still was an upstream
developer for ifupdown, see <https://bugs.debian.org/757291>. The issue
led to this patch was caused by Ubuntu maintainer trying to remove one
of the features he deemed as not yet ready for Ubuntu release, but he
didn't do it properly on the first attempt, thus leading to broken
loopback (which didn't really matter for Ubuntu, as the loopback
interface was configured by upstart there back then).
The correct fix for the issue would be rebasing to the Debian version of
the package which, by the way, has a new active developer, Guus Sliepen.
Then the patch could be dropped.
--
Cheers,
Andrew
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 0/2] add ifupdown @ 2015-09-01 21:34 Joe Slater 2015-09-01 21:34 ` [PATCH 1/2] ifupdown: import recipe Joe Slater 0 siblings, 1 reply; 20+ messages in thread From: Joe Slater @ 2015-09-01 21:34 UTC (permalink / raw) To: openembedded-core I'm not sure where this should go, but these patches are for oe-core. This recipe overrides the versions of ifup and ifdown implemented by busybox, if present. This was copied, with one minor change, from meta-overc, as mentioned in the first patch. Joe Slater (2): ifupdown: import recipe ifupdown: create alternative links meta/recipes-core/ifupdown/files/99_network | 1 + ...-don-t-rely-on-dpkg-architecture-to-set-a.patch | 56 +++++++++++ ...-6-.defn-fix-inverted-checks-for-loopback.patch | 103 ++++++++++++++++++++ meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb | 54 ++++++++++ 4 files changed, 214 insertions(+) create mode 100644 meta/recipes-core/ifupdown/files/99_network create mode 100644 meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch create mode 100644 meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch create mode 100644 meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb -- 1.7.9.5 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/2] ifupdown: import recipe 2015-09-01 21:34 [PATCH 0/2] add ifupdown Joe Slater @ 2015-09-01 21:34 ` Joe Slater 2015-09-02 15:55 ` Otavio Salvador 0 siblings, 1 reply; 20+ messages in thread From: Joe Slater @ 2015-09-01 21:34 UTC (permalink / raw) To: openembedded-core Implements ifup and ifdown. Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9. Signed-off-by: Joe Slater <jslater@windriver.com> --- meta/recipes-core/ifupdown/files/99_network | 1 + ...-don-t-rely-on-dpkg-architecture-to-set-a.patch | 56 +++++++++++ ...-6-.defn-fix-inverted-checks-for-loopback.patch | 103 ++++++++++++++++++++ meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb | 54 ++++++++++ 4 files changed, 214 insertions(+) create mode 100644 meta/recipes-core/ifupdown/files/99_network create mode 100644 meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch create mode 100644 meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch create mode 100644 meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb diff --git a/meta/recipes-core/ifupdown/files/99_network b/meta/recipes-core/ifupdown/files/99_network new file mode 100644 index 0000000..42d5895 --- /dev/null +++ b/meta/recipes-core/ifupdown/files/99_network @@ -0,0 +1 @@ +d root root 0755 /run/network none diff --git a/meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch b/meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch new file mode 100644 index 0000000..8c4d953 --- /dev/null +++ b/meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch @@ -0,0 +1,56 @@ +From 7af9db748974cb3a2c6ef8f9e03d7db1f9f8ee16 Mon Sep 17 00:00:00 2001 +From: Paul Gortmaker <paul.gortmaker@windriver.com> +Date: Wed, 6 Aug 2014 14:54:12 -0400 +Subject: [PATCH 1/2] defn2[c|man]: don't rely on dpkg-architecture to set arch + +In yocto we'll always be cross compiling, and we'll always +be building on linux for linux (vs. *BSD, hurd, etc.) + +Without this the arch is not detected, but it doesn't error +out, and hence you get useless binaries that don't know any +arch specific methods, and the end result will be strangeness +like the loopback device not being configured/enabled. + +Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> +--- + defn2c.pl | 6 +++--- + defn2man.pl | 6 +++--- + 2 files changed, 6 insertions(+), 6 deletions(-) + +diff --git a/defn2c.pl b/defn2c.pl +index c449de2f3d1c..38845e374c76 100755 +--- a/defn2c.pl ++++ b/defn2c.pl +@@ -2,9 +2,9 @@ + + use strict; + +-my $DEB_HOST_ARCH_OS = `dpkg-architecture -qDEB_HOST_ARCH_OS`; +- +-$DEB_HOST_ARCH_OS =~ s/\n//; ++#my $DEB_HOST_ARCH_OS = `dpkg-architecture -qDEB_HOST_ARCH_OS`; ++#$DEB_HOST_ARCH_OS =~ s/\n//; ++my $DEB_HOST_ARCH_OS ="linux"; + + # declarations + my $address_family = ""; +diff --git a/defn2man.pl b/defn2man.pl +index 6ddcfdd4fe68..c9c4dd046597 100755 +--- a/defn2man.pl ++++ b/defn2man.pl +@@ -2,9 +2,9 @@ + + use strict; + +-my $DEB_HOST_ARCH_OS = `dpkg-architecture -qDEB_HOST_ARCH_OS`; +- +-$DEB_HOST_ARCH_OS =~ s/\n//; ++#my $DEB_HOST_ARCH_OS = `dpkg-architecture -qDEB_HOST_ARCH_OS`; ++#$DEB_HOST_ARCH_OS =~ s/\n//; ++my $DEB_HOST_ARCH_OS = "linux"; + + # declarations + my $line; +-- +1.9.1 + diff --git a/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch b/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch new file mode 100644 index 0000000..bff352e --- /dev/null +++ b/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch @@ -0,0 +1,103 @@ +From 74152ac74a3e1ea0f3be292aa1eeca5ad1fe69c0 Mon Sep 17 00:00:00 2001 +From: Paul Gortmaker <paul.gortmaker@windriver.com> +Date: Wed, 6 Aug 2014 15:12:11 -0400 +Subject: [PATCH 2/2] inet[6].defn: fix inverted checks for loopback + +Compared to the hurd link.defn for loopback, we see these +are inverted, meaning that you would only be able to configure +a loopback device that was _not_ named "lo" (unlikely to exist). + +The result was that we'd update /run/network/ifstate for "lo" +but never actually do anything for up/down, as shown below: + +root@localhost:~# ifconfig -s +Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg +eth0 1500 0 7736329 0 2016 0 5289422 0 0 0 BMRU +lo 65536 0 18 0 0 0 18 0 0 0 LRU +root@localhost:~# ifdown lo +root@localhost:~# echo $? +0 +root@localhost:~# ifconfig -s +Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg +eth0 1500 0 7736406 0 2016 0 5289455 0 0 0 BMRU +lo 65536 0 18 0 0 0 18 0 0 0 LRU +root@localhost:~# ifconfig lo down +root@localhost:~# ifconfig -s +Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg +eth0 1500 0 7736474 0 2016 0 5289481 0 0 0 BMRU +root@localhost:~# + +Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> +--- + inet.defn | 12 ++++++------ + inet6.defn | 8 ++++---- + 2 files changed, 10 insertions(+), 10 deletions(-) + +diff --git a/inet.defn b/inet.defn +index b176ab4ed03e..5fdfb14a0e1c 100644 +--- a/inet.defn ++++ b/inet.defn +@@ -6,10 +6,10 @@ method loopback + This method may be used to define the IPv4 loopback interface. + + up +- ip link set dev %iface% up if (!iface_is_lo()) ++ ip link set dev %iface% up if (iface_is_lo()) + + down +- ip link set dev %iface% down if (!iface_is_lo()) ++ ip link set dev %iface% down if (iface_is_lo()) + + method static + description +@@ -212,11 +212,11 @@ method loopback + + up + ifconfig %iface% 127.0.0.1 up \ +- if (!iface_is_lo()) ++ if (iface_is_lo()) + + down + ifconfig %iface% down \ +- if (!iface_is_lo()) ++ if (iface_is_lo()) + + method static + description +@@ -371,11 +371,11 @@ method loopback + + up + inetutils-ifconfig --interface %iface% --address 127.0.0.1 --up \ +- if (!iface_is_lo()) ++ if (iface_is_lo()) + + down + inetutils-ifconfig --interface %iface% --down \ +- if (!iface_is_lo()) ++ if (iface_is_lo()) + + method static + description +diff --git a/inet6.defn b/inet6.defn +index 09325539cd01..4df64aff38cc 100644 +--- a/inet6.defn ++++ b/inet6.defn +@@ -33,11 +33,11 @@ method loopback + description + This method may be used to define the IPv6 loopback interface. + up +- -ip link set dev %iface% up 2>/dev/null if (!iface_is_lo()) +- -ip addr add dev %iface% ::1 2>/dev/null if (!iface_is_lo()) ++ -ip link set dev %iface% up 2>/dev/null if (iface_is_lo()) ++ -ip addr add dev %iface% ::1 2>/dev/null if (iface_is_lo()) + down +- -ip addr del dev %iface% ::1 2>/dev/null if (!iface_is_lo()) +- -ip link set dev %iface% down 2>/dev/null if (!iface_is_lo()) ++ -ip addr del dev %iface% ::1 2>/dev/null if (iface_is_lo()) ++ -ip link set dev %iface% down 2>/dev/null if (iface_is_lo()) + + method static + description +-- +1.9.1 + diff --git a/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb b/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb new file mode 100644 index 0000000..e29cc49 --- /dev/null +++ b/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb @@ -0,0 +1,54 @@ +SUMMARY = "ifupdown: basic ifup and ifdown used by initscripts" +DESCRIPTION = "High level tools to configure network interfaces \ +This package provides the tools ifup and ifdown which may be used to \ +configure (or, respectively, deconfigure) network interfaces, based on \ +the file /etc/network/interfaces." +LICENSE = "GPLv2" +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" + +SRC_URI = "http://archive.ubuntu.com/ubuntu/pool/main/i/ifupdown/ifupdown_0.7.48.1ubuntu5.tar.gz \ + file://defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch \ + file://inet-6-.defn-fix-inverted-checks-for-loopback.patch \ + file://99_network \ + " + +EXTRA_OEMAKE = "" + +# needed so we don't get default S="${WORKDIR}/ifupdown-${PV}" +S = "${WORKDIR}/ifupdown-${PV}ubuntu5" + + +inherit update-rc.d + +do_compile () { + chmod a+rx *.pl *.sh + oe_runmake 'CC=${CC}' "CFLAGS=${CFLAGS} -Wall -W -D'IFUPDOWN_VERSION=\"${PV}\"'" +} + +do_install () { + install -d ${D}${mandir}/man8 \ + ${D}${mandir}/man5 \ + ${D}${base_sbindir} + + # If volatiles are used, then we'll also need /run/network there too. + install -d ${D}/etc/default/volatiles + install -m 0644 ${WORKDIR}/99_network ${D}/etc/default/volatiles + + install -m 0755 ifup ${D}${base_sbindir}/ + ln ${D}${base_sbindir}/ifup ${D}${base_sbindir}/ifdown + install -m 0644 ifup.8 ${D}${mandir}/man8 + install -m 0644 interfaces.5 ${D}${mandir}/man5 + cd ${D}${mandir}/man8 && ln -s ifup.8 ifdown.8 +} + +ALTERNATIVE_PRIORITY = "100" +ALTERNATIVE_${PN} = "ifup ifdown" + +ALTERNATIVE_LINK_NAME[ifup] = "${base_sbindir}/ifup" +ALTERNATIVE_LINK_NAME[ifdown] = "${base_sbindir}/ifdown" + +INITSCRIPT_NAME = "ifup" +INITSCRIPT_PARAMS = "start 39 S . stop 39 0 6 1 ." + +SRC_URI[md5sum] = "85ba375f3c6f26d34efb2a8575e77fc8" +SRC_URI[sha256sum] = "08dce14692c07b72b583b86c4d3ace0d9dac1928925144cc3ddde15b694ebbdf" -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 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-03 12:32 ` Jack Mitchell 0 siblings, 2 replies; 20+ messages in thread From: Otavio Salvador @ 2015-09-02 15:55 UTC (permalink / raw) To: Joe Slater; +Cc: Patches and discussions about the oe-core layer On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote: > Implements ifup and ifdown. > > Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git > as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9. > > Signed-off-by: Joe Slater <jslater@windriver.com> I think this belongs to meta-networking. Also, what this one provides which is not provided by the busybox one? -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 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:32 ` Jack Mitchell 1 sibling, 1 reply; 20+ messages in thread From: Randy MacLeod @ 2015-09-02 19:09 UTC (permalink / raw) To: Otavio Salvador, Joe Slater Cc: Patches and discussions about the oe-core layer On 2015-09-02 11:55 AM, Otavio Salvador wrote: > On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote: >> Implements ifup and ifdown. >> >> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git >> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9. >> >> Signed-off-by: Joe Slater <jslater@windriver.com> > > I think this belongs to meta-networking. Also, what this one provides > which is not provided by the busybox one? > We're trying to make busybox optional for larger systems that want to only use the full-featured/bloated packages. It's not a large tax to carry busybox in a 50+ MB image but it would be nice to not require it. -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-02 19:09 ` Randy MacLeod @ 2015-09-02 19:23 ` Otavio Salvador 2015-09-03 12:11 ` Richard Purdie 0 siblings, 1 reply; 20+ messages in thread From: Otavio Salvador @ 2015-09-02 19:23 UTC (permalink / raw) To: Randy MacLeod; +Cc: Joe Slater, Patches and discussions about the oe-core layer On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod <randy.macleod@windriver.com> wrote: > On 2015-09-02 11:55 AM, Otavio Salvador wrote: >> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote: >>> >>> Implements ifup and ifdown. >>> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9. >>> >>> Signed-off-by: Joe Slater <jslater@windriver.com> >> >> >> I think this belongs to meta-networking. Also, what this one provides >> which is not provided by the busybox one? > > We're trying to make busybox optional for larger systems > that want to only use the full-featured/bloated packages. > It's not a large tax to carry busybox in a 50+ MB image but > it would be nice to not require it. I see; I still think this belongs to meta-networking as it will allow this to be done however won't add new recipes in core. If many people start to use this, we can move this to core. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 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 0 siblings, 2 replies; 20+ messages in thread From: Richard Purdie @ 2015-09-03 12:11 UTC (permalink / raw) To: Otavio Salvador Cc: Patches and discussions about the oe-core layer, Joe Slater On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote: > On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod > <randy.macleod@windriver.com> wrote: > > On 2015-09-02 11:55 AM, Otavio Salvador wrote: > >> > >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote: > >>> > >>> Implements ifup and ifdown. > >>> > >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git > >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9. > >>> > >>> Signed-off-by: Joe Slater <jslater@windriver.com> > >> > >> > >> I think this belongs to meta-networking. Also, what this one provides > >> which is not provided by the busybox one? > > > > We're trying to make busybox optional for larger systems > > that want to only use the full-featured/bloated packages. > > It's not a large tax to carry busybox in a 50+ MB image but > > it would be nice to not require it. > > I see; I still think this belongs to meta-networking as it will allow > this to be done however won't add new recipes in core. > > If many people start to use this, we can move this to core. 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? Cheers, Richard ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 12:11 ` Richard Purdie @ 2015-09-03 12:15 ` Otavio Salvador 2015-09-03 12:20 ` Bruce Ashfield 1 sibling, 0 replies; 20+ messages in thread From: Otavio Salvador @ 2015-09-03 12:15 UTC (permalink / raw) To: Richard Purdie Cc: Joe Slater, Patches and discussions about the oe-core layer On Thu, Sep 3, 2015 at 9:11 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote: >> On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod >> <randy.macleod@windriver.com> wrote: >> > On 2015-09-02 11:55 AM, Otavio Salvador wrote: >> >> >> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote: >> >>> >> >>> Implements ifup and ifdown. >> >>> >> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git >> >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9. >> >>> >> >>> Signed-off-by: Joe Slater <jslater@windriver.com> >> >> >> >> >> >> I think this belongs to meta-networking. Also, what this one provides >> >> which is not provided by the busybox one? >> > >> > We're trying to make busybox optional for larger systems >> > that want to only use the full-featured/bloated packages. >> > It's not a large tax to carry busybox in a 50+ MB image but >> > it would be nice to not require it. >> >> I see; I still think this belongs to meta-networking as it will allow >> this to be done however won't add new recipes in core. >> >> If many people start to use this, we can move this to core. > > 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 is the point; this were not in meta-networking and noone missed it until now. Moving this to oe-core straight seems overkill. I think moving this to meta-networking is right and if many people use it, oe-core is next step. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 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 1 sibling, 1 reply; 20+ messages in thread From: Bruce Ashfield @ 2015-09-03 12:20 UTC (permalink / raw) To: Richard Purdie Cc: Joe Slater, Otavio Salvador, Patches and discussions about the oe-core layer On Thu, Sep 3, 2015 at 8:11 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote: >> On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod >> <randy.macleod@windriver.com> wrote: >> > On 2015-09-02 11:55 AM, Otavio Salvador wrote: >> >> >> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote: >> >>> >> >>> Implements ifup and ifdown. >> >>> >> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git >> >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9. >> >>> >> >>> Signed-off-by: Joe Slater <jslater@windriver.com> >> >> >> >> >> >> I think this belongs to meta-networking. Also, what this one provides >> >> which is not provided by the busybox one? >> > >> > We're trying to make busybox optional for larger systems >> > that want to only use the full-featured/bloated packages. >> > It's not a large tax to carry busybox in a 50+ MB image but >> > it would be nice to not require it. >> >> I see; I still think this belongs to meta-networking as it will allow >> this to be done however won't add new recipes in core. >> >> If many people start to use this, we can move this to core. > > 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. Cheers, Bruce > > Cheers, > > Richard > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 12:20 ` Bruce Ashfield @ 2015-09-03 20:22 ` Khem Raj 2015-09-03 20:27 ` Richard Purdie 2015-09-03 21:28 ` Phil Blundell 0 siblings, 2 replies; 20+ messages in thread From: Khem Raj @ 2015-09-03 20:22 UTC (permalink / raw) To: Bruce Ashfield Cc: Patches and discussions about the oe-core layer, Joe Slater, Otavio Salvador 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 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:15 ` Khem Raj 2015-09-03 21:28 ` Phil Blundell 1 sibling, 2 replies; 20+ messages in thread From: Richard Purdie @ 2015-09-03 20:27 UTC (permalink / raw) To: Khem Raj Cc: Patches and discussions about the oe-core layer, Joe Slater, Otavio Salvador 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 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... Cheers, Richard ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 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:15 ` Khem Raj 1 sibling, 1 reply; 20+ messages in thread From: Otavio Salvador @ 2015-09-03 20:32 UTC (permalink / raw) To: Richard Purdie Cc: Joe Slater, Patches and discussions about the oe-core layer On Thu, Sep 3, 2015 at 5: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 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. So my vote is: - move to meta-networking - for 2.1 we see if it goes to core or not -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 20:32 ` Otavio Salvador @ 2015-09-03 21:02 ` Bruce Ashfield 2015-09-03 21:24 ` Khem Raj 0 siblings, 1 reply; 20+ messages in thread From: Bruce Ashfield @ 2015-09-03 21:02 UTC (permalink / raw) To: Otavio Salvador Cc: Joe Slater, Patches and discussions about the oe-core layer On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador <otavio.salvador@ossystems.com.br> wrote: > On Thu, Sep 3, 2015 at 5: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 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. > > 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 :) > - 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. Cheers, Bruce > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 21:02 ` Bruce Ashfield @ 2015-09-03 21:24 ` Khem Raj 2015-09-03 21:38 ` Bruce Ashfield 0 siblings, 1 reply; 20+ messages in thread From: Khem Raj @ 2015-09-03 21:24 UTC (permalink / raw) To: Bruce Ashfield Cc: Patches and discussions about the oe-core layer, Otavio Salvador, Joe Slater [-- Attachment #1: Type: text/plain, Size: 3432 bytes --] > On Sep 3, 2015, at 2:02 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador > <otavio.salvador@ossystems.com.br> wrote: >> On Thu, Sep 3, 2015 at 5: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 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. > >> - 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. [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 21:24 ` Khem Raj @ 2015-09-03 21:38 ` Bruce Ashfield 0 siblings, 0 replies; 20+ messages in thread From: Bruce Ashfield @ 2015-09-03 21:38 UTC (permalink / raw) To: Khem Raj Cc: Patches and discussions about the oe-core layer, Otavio Salvador, Joe Slater On Thu, Sep 3, 2015 at 5:24 PM, Khem Raj <raj.khem@gmail.com> wrote: > >> On Sep 3, 2015, at 2:02 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: >> >> On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador >> <otavio.salvador@ossystems.com.br> wrote: >>> On Thu, Sep 3, 2015 at 5: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 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" ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 20:27 ` Richard Purdie 2015-09-03 20:32 ` Otavio Salvador @ 2015-09-03 21:15 ` Khem Raj 2015-09-03 21:39 ` Richard Purdie 1 sibling, 1 reply; 20+ messages in thread From: Khem Raj @ 2015-09-03 21:15 UTC (permalink / raw) To: Richard Purdie Cc: Patches and discussions about the oe-core layer, Joe Slater, Otavio Salvador [-- Attachment #1: Type: text/plain, Size: 1882 bytes --] > 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. > > 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. > > 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. [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 21:15 ` Khem Raj @ 2015-09-03 21:39 ` Richard Purdie 2015-09-04 1:12 ` Slater, Joseph 0 siblings, 1 reply; 20+ messages in thread From: Richard Purdie @ 2015-09-03 21:39 UTC (permalink / raw) To: Khem Raj Cc: Patches and discussions about the oe-core layer, Joe Slater, Otavio Salvador 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 21:39 ` Richard Purdie @ 2015-09-04 1:12 ` Slater, Joseph 0 siblings, 0 replies; 20+ messages in thread From: Slater, Joseph @ 2015-09-04 1:12 UTC (permalink / raw) To: Richard Purdie, Khem Raj Cc: Otavio Salvador, Patches and discussions about the oe-core layer > -----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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 20:22 ` Khem Raj 2015-09-03 20:27 ` Richard Purdie @ 2015-09-03 21:28 ` Phil Blundell 2015-09-03 21:46 ` Khem Raj 1 sibling, 1 reply; 20+ messages in thread From: Phil Blundell @ 2015-09-03 21:28 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote: > 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 In general, I don't think it is a good idea for oe-core to be entirely beholden to busybox or any other package, and I would be all in favour of including an alternative implementation for everything that we depend on busybox for. In the specific case of ifupdown, the whole thing seems a little bit 1990s and it's hard to avoid the sense that there are better ways to solve that particular problem nowadays. But oe-core does already include net-tools, which is if anything even more retro (and is in a similar position vis-a-vis busybox) so there is precedent for including this kind of thing. It's also not as if ifupdown is a large piece of software with a complex web of ABI dependencies that will introduce some huge maintenance burden in the future. So I can't see any real downside to adding it to oe-core. p. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-03 21:28 ` Phil Blundell @ 2015-09-03 21:46 ` Khem Raj 0 siblings, 0 replies; 20+ messages in thread From: Khem Raj @ 2015-09-03 21:46 UTC (permalink / raw) To: Phil Blundell; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1761 bytes --] > On Sep 3, 2015, at 2:28 PM, Phil Blundell <pb@pbcl.net> wrote: > > On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote: >> 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 > > In general, I don't think it is a good idea for oe-core to be entirely > beholden to busybox or any other package, and I would be all in favour > of including an alternative implementation for everything that we depend > on busybox for. thats a fine idea, > > In the specific case of ifupdown, the whole thing seems a little bit > 1990s and it's hard to avoid the sense that there are better ways to > solve that particular problem nowadays. But oe-core does already > include net-tools, which is if anything even more retro (and is in a > similar position vis-a-vis busybox) so there is precedent for including > this kind of thing. Yes although replacing net-tools with iproute2 would have been a better one. > > It's also not as if ifupdown is a large piece of software with a complex > web of ABI dependencies that will introduce some huge maintenance burden > in the future. So I can't see any real downside to adding it to > oe-core. It needs maintenance, and if maintainers are fine carrying it is fine too. Added price is future contributions to other areas/packages which have to keep working with this, and there will be patches rejected because they don’t work with this so there is some burden dispersed on development community > > p. > > [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] ifupdown: import recipe 2015-09-02 15:55 ` Otavio Salvador 2015-09-02 19:09 ` Randy MacLeod @ 2015-09-03 12:32 ` Jack Mitchell 1 sibling, 0 replies; 20+ messages in thread From: Jack Mitchell @ 2015-09-03 12:32 UTC (permalink / raw) To: openembedded-core On 02/09/15 16:55, Otavio Salvador wrote: > On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote: >> Implements ifup and ifdown. >> >> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git >> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9. >> >> Signed-off-by: Joe Slater <jslater@windriver.com> > > I think this belongs to meta-networking. Also, what this one provides > which is not provided by the busybox one? > This provides hotplug support which the busybox version does not. I'm torn on where it should land i.e. meta-networking vs core but it is a useful addition regardless. If you're attempting to do a non busybox based build, then I don't see the reasoning for not just using connman as your networking manager instead which is already supported in core. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-10-09 12:24 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-10-09 12:24 [PATCH 1/2] ifupdown: import recipe Andrew Shadura -- strict thread matches above, loose matches on Subject: below -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox