On Tue, Mar 19, 2013 at 6:30 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Tue, 2013-03-19 at 07:44 -0500, Mark Hatle wrote:
> > On 3/19/13 6:35 AM, Richard Purdie wrote:
> > > On Mon, 2013-03-18 at 14:12 -0500, Mark Hatle wrote:
> > >> I found a strange situation today and I'm looking for an explanation
> to see if
> > >> it's a bug or not.
> > >>
> > >> Between a .bb and .bbappend file, I end up with a situation where
> > >> "reproducer.bb" and "reproducer.bbappend" get the following:
> > >>
> > >> RDEPENDS_${PN} += "hello1"
> > >> RDEPENDS_reproducer += "hello2"
> > >>
> > >> When evaluatated (bitbake -e reproducer) I get:
> > >>
> > >> #
> > >> # $RDEPENDS_reproducer [2 operations]
> > >> #   append
> > >> /home/mhatle/git/oss/oe-core/local/recipes-sample/hello/
> reproducer_1.0.bb:16
> > >> #     "hello2"
> > >> #   rename from RDEPENDS_${PN} data.py:161 [expandKeys]
> > >> #     " hello1"
> > >> # computed:
> > >> #   " hello1"
> > >> RDEPENDS_reproducer="hello1"
> > >>
> > >> So that tells me that it was initially set to "hello2", and then the
> ${PN}
> > >> expansion occurred, causing it to be set to "hello1".
> > >>
> > >> So my first question is, should this be "hello1", "hello2", "hello1
> hello2" or
> > >> "hello2 hello1"?
> > >
> > > expandKeys tramples existing values so that result doesn't surprise me
> > > even if its not what you expect.
> > >
> > >> The second issue is a bit stranger.. if I change the build from
> "reproducer" to
> > >> "lib32-reproducer", I get a different result:
> > >>
> > >> # $RDEPENDS_lib32-reproducer [3 operations]
> > >> #   rename from RDEPENDS_${PN} data.py:161 [expandKeys]
> > >> #     " hello1"
> > >> #   rename from RDEPENDS_reproducer classextend.py:95
> [rename_package_variables]
> > >> #     " hello2"
> > >> #   set classextend.py:71 [map_depends_variable]
> > >> #     "lib32-hello2"
> > >> # computed:
> > >> #   "lib32-hello2"
> > >> RDEPENDS_lib32-reproducer="lib32-hello2"
> > >>
> > >> This time the system pulled in the ${PN} version first (obviously
> expanded it),
> > >> and then turned out and found the RDEPENDS_reproducer, and remapped
> it to
> > >> RDEPENDS_lib32-reproducer replacing the origin ${PN} version.
> > >>
> > >> So I have two concerns, the first is the value is 'different' from the
> > >> non-multilib version, and second, what should the expected output be
> for this item?
> > >
> > > Again, I'm not surprised. The multilib remapping code gets executed at
> > > the end, after expandKeys and in this case last wins. So I can see why
> > > the system is doing it, even if you don't like the end result.
> > >
> > > Setting multiple conflicting keys like this is dangerous :(
> > >
> > > We've tried to fix this before and ended up just digging deeper holes
> > > with more problems.
> >
> > Is there any way we can issue a warning from the parser or something
> when it
> > finds conflicting keys?  My concern isn't that conflicting keys are
> causing a
> > problem -- but more that someone may not realize this is a problem, and
> they are
> > getting incorrect results.
> >
> > I know since posting this query, I've had a few people comment to me
> that they
> > saw the same problem and it took them a very long time to diagnose it
> and figure
> > out it "just didn't work".
>
> We could probably have data.expandKeys() check for existing values and
> then error if its overwriting something else. I have no idea how often
> the metadata does that for "correct" reasons...


I expect if the metadata really wants that, it could use a
RecipePreFinalise hook.
-- 
Christopher Larson