[OE-core] [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