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

[richard.purdie@linuxfoundation.org]

On Wed, 2019-06-26 at 18:57 -0400, Sinan Kaya wrote:
> 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 ?

postinst intercepts are there to collect up certain postinst commands
and call them once rather than multiple times during rootfs generation.

There are three different cases:

a) Sometimes we can use a native tool. Here, we run the native tool
with the knowledge that the output it generates is cross compatible.

b) Sometimes we run target binaries under usermode qemu. In this case
the output is target architecture specific and we have no other way to
generate the output other than with the target binary

c) We have a cross tool which can run natively but generate target
output.

> 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?

It depends which scenario above we're dealing with. Sometimes native
recipes are used, sometimes not.

> 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.

The key thing is that these intercept scripts are only run if an image
contains packages which use the postinst. If the image contains the
postinst, the scripts should run correctly.

In that context your patch is concerning as for example you're saying
you can have an image which needs the gio module cache yet it doesn't
have ${libexecdir}/${binprefix}gio-querymodules (the target binary
needed to be run under qemu to generate it). We'd define that as a bug
and you're just hiding the problem with the added conditionals. So on
that basis the patch is clearly incorrect and can't be merged as it
will hide bugs.

Cheers,

Richard