[OE-core] [PATCH] busybox: move default config fragments to defconfig

Richard Purdie richard.purdie at linuxfoundation.org
Thu Mar 30 10:08:48 UTC 2017


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








More information about the Openembedded-core mailing list