[PATCH] busybox: move default config fragments to defconfig

[PATCH] busybox: move default config fragments to defconfig

[Peter Bergin]

Move config fragments that are unconditionally and always applied
to the configuration to the default defconfig file. This will
make it easier to provide your own defconfig file for your target.

The problem this commit will solve is that if you provide your own
defconfig file for your target it will be tampered with by the
configuration fragments in SRC_URI. If you not want those
configurations in your own setup you have to modify SRC_URI
variable in your setup. As those confguration fragment was always
applied it is a better solution to have them in the default
defconfig file instead.

Signed-off-by: Peter Bergin <peter@berginkonsult.se>
---
 meta/recipes-core/busybox/busybox/defconfig        | 64 +++++++++++-----------
 meta/recipes-core/busybox/busybox/getopts.cfg      |  3 -
 .../busybox/busybox/login-utilities.cfg            | 13 -----
 .../busybox/busybox/mount-via-label.cfg            |  9 ---
 meta/recipes-core/busybox/busybox/resize.cfg       |  2 -
 meta/recipes-core/busybox/busybox/sha1sum.cfg      |  1 -
 meta/recipes-core/busybox/busybox/sha256sum.cfg    |  1 -
 meta/recipes-core/busybox/busybox_1.24.1.bb        |  6 --
 8 files changed, 32 insertions(+), 67 deletions(-)
 delete mode 100644 meta/recipes-core/busybox/busybox/getopts.cfg
 delete mode 100644 meta/recipes-core/busybox/busybox/login-utilities.cfg
 delete mode 100644 meta/recipes-core/busybox/busybox/mount-via-label.cfg
 delete mode 100644 meta/recipes-core/busybox/busybox/resize.cfg
 delete mode 100644 meta/recipes-core/busybox/busybox/sha1sum.cfg
 delete mode 100644 meta/recipes-core/busybox/busybox/sha256sum.cfg

diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig
index f649738..4e49b15 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -273,8 +273,8 @@ CONFIG_RM=y
 CONFIG_RMDIR=y
 # CONFIG_FEATURE_RMDIR_LONG_OPTIONS is not set
 CONFIG_SEQ=y
-# CONFIG_SHA1SUM is not set
-# CONFIG_SHA256SUM is not set
+CONFIG_SHA1SUM=y
+CONFIG_SHA256SUM=y
 # CONFIG_SHA512SUM is not set
 # CONFIG_SHA3SUM is not set
 CONFIG_SLEEP=y
@@ -346,8 +346,8 @@ CONFIG_LOADFONT=y
 CONFIG_LOADKMAP=y
 CONFIG_OPENVT=y
 CONFIG_RESET=y
-# CONFIG_RESIZE is not set
-# CONFIG_FEATURE_RESIZE_PRINT is not set
+CONFIG_RESIZE=y
+CONFIG_FEATURE_RESIZE_PRINT=y
 CONFIG_SETCONSOLE=y
 # CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS is not set
 # CONFIG_SETFONT is not set
@@ -473,39 +473,39 @@ CONFIG_MESG=y
 #
 # CONFIG_ADD_SHELL is not set
 # CONFIG_REMOVE_SHELL is not set
-# CONFIG_FEATURE_SHADOWPASSWDS is not set
+CONFIG_FEATURE_SHADOWPASSWDS=y
 # CONFIG_USE_BB_PWD_GRP is not set
 # CONFIG_USE_BB_SHADOW is not set
 CONFIG_USE_BB_CRYPT=y
 # CONFIG_USE_BB_CRYPT_SHA is not set
-# CONFIG_ADDUSER is not set
-# CONFIG_FEATURE_ADDUSER_LONG_OPTIONS is not set
+CONFIG_ADDUSER=y
+CONFIG_FEATURE_ADDUSER_LONG_OPTIONS=y
 # CONFIG_FEATURE_CHECK_NAMES is not set
 CONFIG_LAST_ID=60000
 CONFIG_FIRST_SYSTEM_ID=100
 CONFIG_LAST_SYSTEM_ID=999
-# CONFIG_ADDGROUP is not set
-# CONFIG_FEATURE_ADDGROUP_LONG_OPTIONS is not set
+CONFIG_ADDGROUP=y
+CONFIG_FEATURE_ADDGROUP_LONG_OPTIONS=y
 # CONFIG_FEATURE_ADDUSER_TO_GROUP is not set
-# CONFIG_DELUSER is not set
-# CONFIG_DELGROUP is not set
+CONFIG_DELUSER=y
+CONFIG_DELGROUP=y
 # CONFIG_FEATURE_DEL_USER_FROM_GROUP is not set
-# CONFIG_GETTY is not set
-# CONFIG_LOGIN is not set
+CONFIG_GETTY=y
+CONFIG_LOGIN=y
 # CONFIG_LOGIN_SESSION_AS_CHILD is not set
 # CONFIG_LOGIN_SCRIPTS is not set
 # CONFIG_FEATURE_NOLOGIN is not set
 # CONFIG_FEATURE_SECURETTY is not set
-# CONFIG_PASSWD is not set
+CONFIG_PASSWD=y
 # CONFIG_FEATURE_PASSWD_WEAK_CHECK is not set
 # CONFIG_CRYPTPW is not set
 # CONFIG_CHPASSWD is not set
 CONFIG_FEATURE_DEFAULT_PASSWD_ALGO=""
-# CONFIG_SU is not set
+CONFIG_SU=y
 # CONFIG_FEATURE_SU_SYSLOG is not set
 # CONFIG_FEATURE_SU_CHECKS_SHELLS is not set
-# CONFIG_SULOGIN is not set
-# CONFIG_VLOCK is not set
+CONFIG_SULOGIN=y
+CONFIG_VLOCK=y
 
 #
 # Linux Ext2 FS Progs
@@ -562,7 +562,7 @@ CONFIG_MOUNT=y
 # CONFIG_FEATURE_MOUNT_FAKE is not set
 # CONFIG_FEATURE_MOUNT_VERBOSE is not set
 # CONFIG_FEATURE_MOUNT_HELPERS is not set
-# CONFIG_FEATURE_MOUNT_LABEL is not set
+CONFIG_FEATURE_MOUNT_LABEL=y
 # CONFIG_FEATURE_MOUNT_NFS is not set
 # CONFIG_FEATURE_MOUNT_CIFS is not set
 CONFIG_FEATURE_MOUNT_FLAGS=y
@@ -572,8 +572,8 @@ CONFIG_FEATURE_MOUNT_FSTAB=y
 # CONFIG_UEVENT is not set
 # CONFIG_ACPID is not set
 # CONFIG_FEATURE_ACPID_COMPAT is not set
-# CONFIG_BLKID is not set
-# CONFIG_FEATURE_BLKID_TYPE is not set
+CONFIG_BLKID=y
+CONFIG_FEATURE_BLKID_TYPE=y
 CONFIG_DMESG=y
 CONFIG_FEATURE_DMESG_PRETTY=y
 CONFIG_FBSET=y
@@ -599,8 +599,8 @@ CONFIG_FLOCK=y
 # CONFIG_FEATURE_MINIX2 is not set
 # CONFIG_MKFS_REISER is not set
 # CONFIG_MKFS_VFAT is not set
-# CONFIG_GETOPT is not set
-# CONFIG_FEATURE_GETOPT_LONG is not set
+CONFIG_GETOPT=y
+CONFIG_FEATURE_GETOPT_LONG=y
 CONFIG_HEXDUMP=y
 # CONFIG_FEATURE_HEXDUMP_REVERSE is not set
 # CONFIG_HD is not set
@@ -636,13 +636,17 @@ CONFIG_FEATURE_UMOUNT_ALL=y
 CONFIG_FEATURE_MOUNT_LOOP=y
 CONFIG_FEATURE_MOUNT_LOOP_CREATE=y
 # CONFIG_FEATURE_MTAB_SUPPORT is not set
-# CONFIG_VOLUMEID is not set
-# CONFIG_FEATURE_VOLUMEID_BTRFS is not set
+CONFIG_VOLUMEID=y
+
+#
+# Filesystem/Volume identification
+#
+CONFIG_FEATURE_VOLUMEID_BTRFS=y
 # CONFIG_FEATURE_VOLUMEID_CRAMFS is not set
 # CONFIG_FEATURE_VOLUMEID_EXFAT is not set
-# CONFIG_FEATURE_VOLUMEID_EXT is not set
-# CONFIG_FEATURE_VOLUMEID_F2FS is not set
-# CONFIG_FEATURE_VOLUMEID_FAT is not set
+CONFIG_FEATURE_VOLUMEID_EXT=y
+CONFIG_FEATURE_VOLUMEID_F2FS=y
+CONFIG_FEATURE_VOLUMEID_FAT=y
 # CONFIG_FEATURE_VOLUMEID_HFS is not set
 # CONFIG_FEATURE_VOLUMEID_ISO9660 is not set
 # CONFIG_FEATURE_VOLUMEID_JFS is not set
@@ -654,7 +658,7 @@ CONFIG_FEATURE_MOUNT_LOOP_CREATE=y
 # CONFIG_FEATURE_VOLUMEID_OCFS2 is not set
 # CONFIG_FEATURE_VOLUMEID_REISERFS is not set
 # CONFIG_FEATURE_VOLUMEID_ROMFS is not set
-# CONFIG_FEATURE_VOLUMEID_SQUASHFS is not set
+CONFIG_FEATURE_VOLUMEID_SQUASHFS=y
 # CONFIG_FEATURE_VOLUMEID_SYSV is not set
 # CONFIG_FEATURE_VOLUMEID_UDF is not set
 # CONFIG_FEATURE_VOLUMEID_XFS is not set
@@ -981,10 +985,6 @@ CONFIG_SV_DEFAULT_SERVICE_DIR=""
 # CONFIG_ENVUIDGID is not set
 # CONFIG_ENVDIR is not set
 # CONFIG_SOFTLIMIT is not set
-
-#
-#  SELinux utilities
-#
 # CONFIG_CHCON is not set
 # CONFIG_FEATURE_CHCON_LONG_OPTIONS is not set
 # CONFIG_GETENFORCE is not set
diff --git a/meta/recipes-core/busybox/busybox/getopts.cfg b/meta/recipes-core/busybox/busybox/getopts.cfg
deleted file mode 100644
index 8db0a4a..0000000
--- a/meta/recipes-core/busybox/busybox/getopts.cfg
+++ /dev/null
@@ -1,3 +0,0 @@
-CONFIG_GETOPT=y
-CONFIG_LONG_OPTS=y
-CONFIG_FEATURE_GETOPT_LONG=y
diff --git a/meta/recipes-core/busybox/busybox/login-utilities.cfg b/meta/recipes-core/busybox/busybox/login-utilities.cfg
deleted file mode 100644
index cc9b2db..0000000
--- a/meta/recipes-core/busybox/busybox/login-utilities.cfg
+++ /dev/null
@@ -1,13 +0,0 @@
-CONFIG_FEATURE_SHADOWPASSWDS=y
-CONFIG_ADDUSER=y
-CONFIG_FEATURE_ADDUSER_LONG_OPTIONS=y
-CONFIG_ADDGROUP=y
-CONFIG_FEATURE_ADDGROUP_LONG_OPTIONS=y
-CONFIG_DELUSER=y
-CONFIG_DELGROUP=y
-CONFIG_GETTY=y
-CONFIG_LOGIN=y
-CONFIG_PASSWD=y
-CONFIG_SU=y
-CONFIG_SULOGIN=y
-CONFIG_VLOCK=y
diff --git a/meta/recipes-core/busybox/busybox/mount-via-label.cfg b/meta/recipes-core/busybox/busybox/mount-via-label.cfg
deleted file mode 100644
index 2fe7ab2..0000000
--- a/meta/recipes-core/busybox/busybox/mount-via-label.cfg
+++ /dev/null
@@ -1,9 +0,0 @@
-CONFIG_BLKID=y
-CONFIG_FEATURE_BLKID_TYPE=y
-CONFIG_FEATURE_MOUNT_LABEL=y
-CONFIG_VOLUMEID=y
-CONFIG_FEATURE_VOLUMEID_BTRFS=y
-CONFIG_FEATURE_VOLUMEID_EXT=y
-CONFIG_FEATURE_VOLUMEID_F2FS=y
-CONFIG_FEATURE_VOLUMEID_FAT=y
-CONFIG_FEATURE_VOLUMEID_SQUASHFS=y
diff --git a/meta/recipes-core/busybox/busybox/resize.cfg b/meta/recipes-core/busybox/busybox/resize.cfg
deleted file mode 100644
index a1d9c95..0000000
--- a/meta/recipes-core/busybox/busybox/resize.cfg
+++ /dev/null
@@ -1,2 +0,0 @@
-CONFIG_RESIZE=y
-CONFIG_FEATURE_RESIZE_PRINT=y
diff --git a/meta/recipes-core/busybox/busybox/sha1sum.cfg b/meta/recipes-core/busybox/busybox/sha1sum.cfg
deleted file mode 100644
index 20e72d9..0000000
--- a/meta/recipes-core/busybox/busybox/sha1sum.cfg
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_SHA1SUM=y
diff --git a/meta/recipes-core/busybox/busybox/sha256sum.cfg b/meta/recipes-core/busybox/busybox/sha256sum.cfg
deleted file mode 100644
index ce652ae..0000000
--- a/meta/recipes-core/busybox/busybox/sha256sum.cfg
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_SHA256SUM=y
diff --git a/meta/recipes-core/busybox/busybox_1.24.1.bb b/meta/recipes-core/busybox/busybox_1.24.1.bb
index 41fc641..5a338dc 100644
--- a/meta/recipes-core/busybox/busybox_1.24.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.24.1.bb
@@ -25,7 +25,6 @@ SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
            file://run-ptest \
            file://inetd.conf \
            file://inetd \
-           file://login-utilities.cfg \
            file://recognize_connmand.patch \
            file://busybox-cross-menuconfig.patch \
            file://0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch \
@@ -33,11 +32,6 @@ SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
            file://busybox-1.24.1-unzip-regression.patch \
            file://busybox-1.24.1-truncate-open-mode.patch \
            file://0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch \
-           file://mount-via-label.cfg \
-           file://sha1sum.cfg \
-           file://sha256sum.cfg \
-           file://getopts.cfg \
-           file://resize.cfg \
            ${@["", "file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'busybox')]} \
            ${@["", "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager') == 'busybox-mdev')]} \
            file://inittab \
-- 
2.7.4

Re: [PATCH] busybox: move default config fragments to defconfig

[Richard Purdie]

On Tue, 2017-03-28 at 22:08 +0200, Peter Bergin wrote:
> Move config fragments that are unconditionally and always applied
> to the configuration to the default defconfig file. This will
> make it easier to provide your own defconfig file for your target.
> 
> The problem this commit will solve is that if you provide your own
> defconfig file for your target it will be tampered with by the
> configuration fragments in SRC_URI. If you not want those
> configurations in your own setup you have to modify SRC_URI
> variable in your setup. As those confguration fragment was always
> applied it is a better solution to have them in the default
> defconfig file instead.

This basically removes any standard feature grouping from being used in
the base busybox recipe. I don't think this is something we want to
encourage, I'd actually like to see more feature group usage.

So we need to find some other way of solving your issue.

Cheers,

Richard

Re: [PATCH] busybox: move default config fragments to defconfig

[Peter Bergin]

On 2017-03-29 01:02, Richard Purdie wrote:
> On Tue, 2017-03-28 at 22:08 +0200, Peter Bergin wrote:
>> Move config fragments that are unconditionally and always applied
>> to the configuration to the default defconfig file. This will
>> make it easier to provide your own defconfig file for your target.
>>
>> The problem this commit will solve is that if you provide your own
>> defconfig file for your target it will be tampered with by the
>> configuration fragments in SRC_URI. If you not want those
>> configurations in your own setup you have to modify SRC_URI
>> variable in your setup. As those confguration fragment was always
>> applied it is a better solution to have them in the default
>> defconfig file instead.
> This basically removes any standard feature grouping from being used in
> the base busybox recipe. I don't think this is something we want to
> encourage, I'd actually like to see more feature group usage.
>
> So we need to find some other way of solving your issue.
>
> Cheers,
>
> Richard

I agree that it is nice and encouraged to group configurations together 
and make them selectable as a group. A good example from 
busybox_1.24.1.bb is:

            ${@["", 
"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 
'busybox')]} \
            ${@["", 
"file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager') == 
'busybox-mdev')]} \

In the example above, configuration fragments are added based on some 
configuration in your build. The configuration fragments that I removed 
with my patch was always added and in that situation I think it is 
better that they are added to the defconfig file. The situation now 
force me to do workarounds to avoid having these default configurations 
in my busybox .config.

Ideas for better solutions are welcome and I hope we can find a solution 
that make it possible to provide your own busybox defconfig file that is 
only changed due to configurations in your build.

Best regards,
/Peter

Re: [PATCH] busybox: move default config fragments to defconfig

[Richard Purdie]

On Wed, 2017-03-29 at 10:16 +0200, Peter Bergin wrote:
> I agree that it is nice and encouraged to group configurations
> together and make them selectable as a group. A good example from 
> busybox_1.24.1.bb is:
> 
>             ${@["", 
> "file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 
> 'busybox')]} \
>             ${@["", 
> "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager') == 
> 'busybox-mdev')]} \
> 
> In the example above, configuration fragments are added based on some
> configuration in your build. The configuration fragments that I
> removed with my patch was always added and in that situation I think
> it is better that they are added to the defconfig file. The situation
> now force me to do workarounds to avoid having these default
> configurations in my busybox .config.
> 
> Ideas for better solutions are welcome and I hope we can find a
> solution that make it possible to provide your own busybox defconfig
> file that is only changed due to configurations in your build.

I don't think its difficult to make something which would improve
things and be configurable from other layers. How about something like:

diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index 6246c95..cb20207 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -15,6 +15,11 @@ SECTION = "base"
 # Whether to split the suid apps into a seperate binary
 BUSYBOX_SPLIT_SUID ?= "1"
 
+BUSYBOX_FRAGMENTS = "login-utilities"
+
+def busybox_fragment(name, d):
+    return bb.utils.contains('BUSYBOX_FRAGMENTS', name, "file://" + name + ".cfg", "", d)
+
 export EXTRA_CFLAGS = "${CFLAGS}"
 export EXTRA_LDFLAGS = "${LDFLAGS}"
 
diff --git a/meta/recipes-core/busybox/busybox_1.24.1.bb b/meta/recipes-core/busybox/busybox_1.24.1.bb
index 41fc641..a0ef17b 100644
--- a/meta/recipes-core/busybox/busybox_1.24.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.24.1.bb
@@ -25,7 +25,7 @@ SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
            file://run-ptest \
            file://inetd.conf \
            file://inetd \
-           file://login-utilities.cfg \
+           ${@busybox_fragment("login-utilities", d)} \
            file://recognize_connmand.patch \
            file://busybox-cross-menuconfig.patch \
            file://0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch \

Obviously I just used login-utilities as an example...

Cheers,

Richard

Re: [PATCH] busybox: move default config fragments to defconfig

[Peter Bergin]

On 2017-03-29 12:22, Richard Purdie wrote:
> On Wed, 2017-03-29 at 10:16 +0200, Peter Bergin wrote:
>> I agree that it is nice and encouraged to group configurations
>> together and make them selectable as a group. A good example from
>> busybox_1.24.1.bb is:
>>
>>              ${@["",
>> "file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') ==
>> 'busybox')]} \
>>              ${@["",
>> "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager') ==
>> 'busybox-mdev')]} \
>>
>> In the example above, configuration fragments are added based on some
>> configuration in your build. The configuration fragments that I
>> removed with my patch was always added and in that situation I think
>> it is better that they are added to the defconfig file. The situation
>> now force me to do workarounds to avoid having these default
>> configurations in my busybox .config.
>>
>> Ideas for better solutions are welcome and I hope we can find a
>> solution that make it possible to provide your own busybox defconfig
>> file that is only changed due to configurations in your build.
> I don't think its difficult to make something which would improve
> things and be configurable from other layers. How about something like:
>
> diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
> index 6246c95..cb20207 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -15,6 +15,11 @@ SECTION = "base"
>   # Whether to split the suid apps into a seperate binary
>   BUSYBOX_SPLIT_SUID ?= "1"
>   
> +BUSYBOX_FRAGMENTS = "login-utilities"
> +
> +def busybox_fragment(name, d):
> +    return bb.utils.contains('BUSYBOX_FRAGMENTS', name, "file://" + name + ".cfg", "", d)
> +
>   export EXTRA_CFLAGS = "${CFLAGS}"
>   export EXTRA_LDFLAGS = "${LDFLAGS}"
>   
> diff --git a/meta/recipes-core/busybox/busybox_1.24.1.bb b/meta/recipes-core/busybox/busybox_1.24.1.bb
> index 41fc641..a0ef17b 100644
> --- a/meta/recipes-core/busybox/busybox_1.24.1.bb
> +++ b/meta/recipes-core/busybox/busybox_1.24.1.bb
> @@ -25,7 +25,7 @@ SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
>              file://run-ptest \
>              file://inetd.conf \
>              file://inetd \
> -           file://login-utilities.cfg \
> +           ${@busybox_fragment("login-utilities", d)} \
>              file://recognize_connmand.patch \
>              file://busybox-cross-menuconfig.patch \
>              file://0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch \
>
> Obviously I just used login-utilities as an example...
>
> Cheers,
>
> Richard
>
Thanks for your suggestion. I think this is one step better than what's 
in master today as it can more easily be overridden. But I don't think 
this is a better solution to the problem than moving the defaults to the 
defconfig. Probably I have a bit different view of grouping the config 
features. I think that the grouping in .cfg fragments is a good design 
if you have features that you enable for example via DISTRO_FEATURE or 
VIRTUAL-RUNTIME_init_manager or some other feature option that is 
present in the build system. As in the examples with mbox.cfg and init.cfg.

I think grouping of configurations because they belong together is a 
task for busybox's Kconfig. In the Kconfig system for busybox you can 
see the options you have and their relations. If you start a project and 
want to tune busybox the natural place to do it is in the defconfig 
file. And modifying the defconfig file with help of menuconfig.

What pros do you see of having standard feature .cfg files in SRC_URI 
that are (default) always added instead of having them in the defconfig? 
How does it help the developer/maintainer?

Best regards,
/Peter

Re: [PATCH] busybox: move default config fragments to defconfig

[Richard Purdie]

On Wed, 2017-03-29 at 19:19 +0200, Peter Bergin wrote:
> Thanks for your suggestion. I think this is one step better than
> what's  in master today as it can more easily be overridden. But I
> don't think  this is a better solution to the problem than moving the
> defaults to the defconfig. Probably I have a bit different view of
> grouping the config features. I think that the grouping in .cfg
> fragments is a good design if you have features that you enable for
> example via DISTRO_FEATURE or VIRTUAL-RUNTIME_init_manager or some
> other feature option that is present in the build system. As in the
> examples with mbox.cfg and init.cfg.
> 
> I think grouping of configurations because they belong together is a 
> task for busybox's Kconfig. In the Kconfig system for busybox you can
> see the options you have and their relations. If you start a project
> and want to tune busybox the natural place to do it is in the
> defconfig file. And modifying the defconfig file with help of
> menuconfig.
> 
> What pros do you see of having standard feature .cfg files in SRC_URI
> that are (default) always added instead of having them in the
> defconfig? How does it help the developer/maintainer?

I can see cases where there is a logic group of features (such as
login-utilities) where there isn't a corresponding DISTRO_FEATURE or
VIRTUAL-RUNTIME yet we do want the developer/maintainer being able to
turn that group of things on/off, depending on the rest of their system
/distro setup.

I do agree that some of the smaller configs are a little unusual, but
even those do actually have uses since for example people have security
policies which may "ban" sha1 due to its vulnerabilities. With your
proposal they'd be forced into providing their own complete defconfig
which I don't think does anyone any favours where as today, they can
control that single thing but inherit our defaults.

I'd like to encourage more inheritance, not less. Equally, you do have
a valid problem in wanting to control things entirely and I'm trying to
give you a solution which can work for everyone.

Cheers,

Richard

Re: [PATCH] busybox: move default config fragments to defconfig

[Richard Purdie]

On Wed, 2017-03-29 at 10:16 +0200, Peter Bergin wrote:
> On 2017-03-29 01:02, Richard Purdie wrote:
> > 
> > On Tue, 2017-03-28 at 22:08 +0200, Peter Bergin wrote:
> > > 
> > > Move config fragments that are unconditionally and always applied
> > > to the configuration to the default defconfig file. This will
> > > make it easier to provide your own defconfig file for your
> > > target.
> > > 
> > > The problem this commit will solve is that if you provide your
> > > own
> > > defconfig file for your target it will be tampered with by the
> > > configuration fragments in SRC_URI. If you not want those
> > > configurations in your own setup you have to modify SRC_URI
> > > variable in your setup. As those confguration fragment was always
> > > applied it is a better solution to have them in the default
> > > defconfig file instead.
> > This basically removes any standard feature grouping from being
> > used in
> > the base busybox recipe. I don't think this is something we want to
> > encourage, I'd actually like to see more feature group usage.
> > 
> > So we need to find some other way of solving your issue.
> > 
> > Cheers,
> > 
> > Richard
> I agree that it is nice and encouraged to group configurations
> together and make them selectable as a group.

Also, in case its not apparent, you can work around this today by
providing empty fragment files in your own layer. These would override
the default ones in the main recipe if you set it up right.

Cheers,

Richard

Re: [PATCH] busybox: move default config fragments to defconfig

[Andre McCurdy]

On Wed, Mar 29, 2017 at 3:24 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> Also, in case its not apparent, you can work around this today by
> providing empty fragment files in your own layer. These would override
> the default ones in the main recipe if you set it up right.

Or use SRC_URI_remove = "file://login-utilities.cfg" etc.

> Cheers,
>
> Richard
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] busybox: move default config fragments to defconfig

[Ulrich Ölmann]

On Wed, Mar 29, 2017 at 08:23:00AM -0700, Andre McCurdy wrote:
> On Wed, Mar 29, 2017 at 3:24 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > Also, in case its not apparent, you can work around this today by
> > providing empty fragment files in your own layer. These would override
> > the default ones in the main recipe if you set it up right.
> 
> Or use SRC_URI_remove = "file://login-utilities.cfg" etc.

But for both suggested approaches you need to know the existance and name of the
config fragment file(s), don't you?

Regards
Ulrich
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH] busybox: move default config fragments to defconfig

[Peter Bergin]

On 2017-03-29 19:25, Ulrich Ölmann wrote:
> On Wed, Mar 29, 2017 at 08:23:00AM -0700, Andre McCurdy wrote:
>> On Wed, Mar 29, 2017 at 3:24 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> Also, in case its not apparent, you can work around this today by
>>> providing empty fragment files in your own layer. These would override
>>> the default ones in the main recipe if you set it up right.
>> Or use SRC_URI_remove = "file://login-utilities.cfg" etc.
> But for both suggested approaches you need to know the existance and name of the
> config fragment file(s), don't you?
>
> Regards
> Ulrich

That is correct. With these approaches you need to specify all present 
.cfg files either in SRC_URI_remove or as empty files in your local layer.

Best regards,
/Peter