[OE-core] [PATCH 1/2] populate_sdk_ext: consider custom configuration in local.conf

[Paul Eggleton]

On Wednesday 29 April 2015 09:59:37 Richard Purdie wrote:
> On Wed, 2015-04-29 at 09:54 +0100, Paul Eggleton wrote:
> > On Wednesday 29 April 2015 16:08:36 Chen Qi wrote:
> > > Copy the contents of local.conf under TOPDIR into the final generated
> > > local.conf. In this way, custom settings are also made into the final
> > > local.conf like IMAGE_INSTALL, DISTRO_FEATURES, VIRTUAL-RUNTIME_xxx,
> > > etc.
> > > 
> > > Before this change, installing extensible SDK would usually report
> > > failure
> > > when preparing the build system if the user has custom configuration for
> > > DISTRO_FEATURES in local.conf. Also, items in IMAGE_INSTALL_append in
> > > local.conf also don't get built correctly.
> > > 
> > > This patch solves the above problem.
> > > 
> > > A blacklist mechanism is also introduced so that we can blacklist
> > > variables
> > > that should not be copied into the final local.conf file. Currently, the
> > > blacklist contains 'SSTATE_DIR' and 'DL_DIR'.
> > > 
> > > [YOCTO #7616]
> > > 
> > > Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
> > > ---
> > > 
> > >  meta/classes/populate_sdk_ext.bbclass | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/meta/classes/populate_sdk_ext.bbclass
> > > b/meta/classes/populate_sdk_ext.bbclass index dc2c58e..7925ece 100644
> > > --- a/meta/classes/populate_sdk_ext.bbclass
> > > +++ b/meta/classes/populate_sdk_ext.bbclass
> > > @@ -16,6 +16,7 @@ SDK_RDEPENDS_append_task-populate-sdk-ext = "
> > > ${SDK_TARGETS}" SDK_RELOCATE_AFTER_INSTALL_task-populate-sdk-ext = "0"
> > > 
> > >  SDK_META_CONF_WHITELIST ?= "MACHINE DISTRO PACKAGE_CLASSES"
> > > 
> > > +SDK_META_CONF_BLACKLIST ?= "DL_DIR SSTATE_DIR"
> > 
> > I'm not totally opposed to this approach but we are going to have to get
> > the default list right if we are going to do it - e.g. you've missed the
> > fairly obvious TMPDIR. There are quite a large number of other variables
> > the user might set that should be blacklisted - potentially any variable
> > that points to a location where the build system would write files
> > (DEPLOY_DIR, DEPLOY_DIR_*, WORKDIR, T, S, B, ...). We might go a step
> > further and use the data dictionary to check if the value evaluates to
> > somewhere outside of ${TMPDIR} (if we first make a copy of d and set
> > TMPDIR to a dummy value); this way we would allow adjustments within
> > TMPDIR but not outside of it.
> > 
> > My other concern (perhaps a pet issue of mine) is that people are far too
> > reliant on putting things in local.conf that they really shouldn't. On the
> > other hand building a potentially broken SDK or at least one that doesn't
> > match up with the image is worse, but I'm still concerned about the way
> > local.conf is often abused.
> 
> One thing we could do programatically is to build the bash config hash
> with and without local.conf. If they match, local.conf isn't influencing
> the build checksums. If they don't match, local.conf has something
> problematic in it and we could error and tell the user to fix it?
> 
> This would also cover site.conf, auto.conf and the other conf files we
> can detect.

Hmm, yes... this might be another check we could turn on when switching from 
development -> production (what I mentioned at OEDAM).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre