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