[OE-core] [PATCH v1] postinst-intercepts: check tool presence in intercept hooks

[Sinan Kaya]

On 6/26/2019 5:21 PM, Richard Purdie wrote:
>> What is so special about these?
> Put another way, why aren't lots of people seeing failures due to this?
> 
> You're obviously doing something differently to everyone else but we're
> having a hard time understanding what, or how we'd trigger the problem
> you're seeing. 
> 
> We're nervous about fixing problems we don't understand, not least as
> it potentially means we have a huge hole in our test matrix. Your
> patches shouldn't be necessary as I understand the codebase either.

Let's see if we can peel the onion.

Can you explain how it was designed to work for cross compilation use
case where host machine architecture != target machine architecture ?

If I understand this right, all of these postinst intercepts create
a native package dependency via inherit foobar.class.

AFAIK, Native packages are built against the host machine architecture
not target architecture.

Where are the tools supposed to come from?

I can focus on details if my build actually follows the design.

As I said, I do not want these packages on my target machine but we
want to run QEMU using the tools that were compiled against target
machine in order to execute postinst intercepts.

This issue showed up in thud using core-image-minimal. It was not there
on sumo.