From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2] populate_sdk_ext: consider custom configuration in local.conf
Date: Wed, 29 Apr 2015 09:59:37 +0100 [thread overview]
Message-ID: <1430297977.19130.5.camel@linuxfoundation.org> (raw)
In-Reply-To: <1574592.uPXveHVxj5@peggleto-mobl.ger.corp.intel.com>
On Wed, 2015-04-29 at 09:54 +0100, Paul Eggleton wrote:
> Hi Qi,
>
> 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@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.
Cheers,
Richard
next prev parent reply other threads:[~2015-04-29 8:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-29 8:08 [PATCH 0/2] populate_sdk_ext: two fixes Chen Qi
2015-04-29 8:08 ` [PATCH 1/2] populate_sdk_ext: consider custom configuration in local.conf Chen Qi
2015-04-29 8:54 ` Paul Eggleton
2015-04-29 8:59 ` Richard Purdie [this message]
2015-04-29 9:02 ` Paul Eggleton
2015-04-29 8:08 ` [PATCH 2/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi
2015-04-29 8:58 ` Paul Eggleton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1430297977.19130.5.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.