From: Olof Johansson <olof.johansson@axis.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: Variable key replaces original warnings
Date: Fri, 31 Jul 2015 13:42:40 +0200 [thread overview]
Message-ID: <1438336631-sup-5239@axis.com> (raw)
In-Reply-To: <1438336442.22462.2.camel@linuxfoundation.org>
Excerpts from Richard Purdie's message of 2015-07-31 11:54:02 +0200:
> On Thu, 2015-07-30 at 17:03 +0200, Olof Johansson wrote:
> > I made a unit test that should demonstrate the problem (I think), and it fails
> > because of the warnings:
> >
> > diff --git a/bitbake/lib/bb/tests/data.py b/bitbake/lib/bb/tests/data.py
> > index e9aab57..e7716cc 100644
> > --- a/bitbake/lib/bb/tests/data.py
> > +++ b/bitbake/lib/bb/tests/data.py
> > @@ -386,6 +386,15 @@ class TestKeyExpansion(unittest.TestCase):
> > self.assertTrue(logContains("Variable key VAL_${FOO} (A) replaces original key VAL_foo (B)", logs))
> > self.assertEqual(self.d.getVar("VAL_foo", True), "A")
> >
> > + def test_append(self):
> > + self.d.setVar("TEST_${BAR}", "Bar")
> > + self.d.setVar("TEST_${FOO}_append", "Foo")
> > + with LogRecord() as logs:
> > + bb.data.expandKeys(self.d)
> > + self.assertFalse(logContains("Variable key TEST_${FOO} (Foo) replaces original key TEST_foo (Bar)", logs))
> > + self.assertEqual(self.d.getVar("TEST_${FOO}", True), "BarFoo")
> >
> >
> > If you have any ideas on what this issue can be or how to fix it, please
> > let me know :)
>
> The data store changes recently caused a number of these to appear. The
> issue has always been there, as has this warning, the new datastore code
> just exposes it a bit more consistently than previously.
>
> The reason we do this is that users with conflicting (different values)
> of the same variable name usually have a metadata issue they're unaware
> of.
Thanks. But that's not the case for us. Why is this relevant for _append
operations? The exanded variable does get the expected value (which can
be verified by uncommenting the assertFalse for the log in my unit
test).
> The fix is to ensure you only set a variable in one canonical way.
Why? For our purpose that's not ideal. We want to be able to create a
user with a common definition from a set of packages. It's not
necessarily the recipes' ${PN} package that will create such a user.
--
olof johansson
prev parent reply other threads:[~2015-07-31 11:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 15:03 Variable key replaces original warnings Olof Johansson
2015-07-31 9:54 ` Richard Purdie
2015-07-31 10:00 ` Richard Purdie
2015-07-31 11:48 ` Olof Johansson
2015-07-31 15:42 ` Richard Purdie
2015-07-31 11:42 ` Olof Johansson [this message]
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=1438336631-sup-5239@axis.com \
--to=olof.johansson@axis.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox