[OE-core] Adding a "tiny" DISTRO_FEATURE and having packages build smaller

[Daniel F. Dickinson]

On 01/02/18 09:12 AM, Burton, Ross wrote:
> On 1 February 2018 at 14:10, Daniel F. Dickinson <cshored at thecshore.com 
> <mailto:cshored at thecshore.com>> wrote:
> 
>     On 01/02/18 08:54 AM, Burton, Ross wrote:
> 
>         On 1 February 2018 at 13:44, Daniel F. Dickinson
>         <cshored at thecshore.com <mailto:cshored at thecshore.com>
>         <mailto:cshored at thecshore.com <mailto:cshored at thecshore.com>>>
>         wrote:
> 
>              I guess the question is would it be useful to have a flag
>         that chooses
>              a 'typical' tinyness but can be overridden (I'm think here of
>              avoiding having to specify huge numbers of PACKAGECONFIGs for a
>              typical tiny case, when really you want most of the 'normal'
>              tinyness with some
>              tweaks.  What I'm think is that "tiny" really should just
>         change the
>              defaults for PACKAGECONFIG etc, but like the defaults can
>         be easily
>              overridden.
> 
> 
>         Well in the idiomatic way the default would be "all the things
>         are on", so doing a "tiny" build would be just setting
>         PACKAGECONFIG="".
> 
>         When we're dealing with tiny configurations you can't really say
>         "and this is what people will want", because that's precisely
>         the problem: you don't know what someone else will want.
> 
>         Ross
> 
>     Fair enough.  Is there a way to distribute a set of package configs
>     and/or package selections (can a packagegroup do packageconfig or
>     does that need to be specified in a different scope (I'm still
>     getting used to openembedded)).  "tiny" is a bad choice because it's
>     too generic, but perhaps "meta-tiny-router" "meta-tiny-switch"
>     "meta-tiny-home-device" etc would make sense as mini-layers that
>     could take care of sane defaults for different use cases (assuming
>     the work of splitting packages up more and appropriate tinification
>     PACKAGECONFIGs are either submitted to the appropriate layer or
>     bbappended in various layers)?
> 
> 
> A distribution can set other recipe's PACKAGECONFIGs directly:
> 
> PACKAGECONFIG_pn-recipename = "foo bar"
> 
> And distributions are welcome to bundle groups of those into inc files 
> for the user to pull in as required at the distro level.
> 
> Ross
I wonder if it'd be useful to have some .inc's of this variety added and 
included (commented out) in the poky-tiny distro default local.conf?