[OE-core] new meta-oe failures from master-next

[richard.purdie at linuxfoundation.org]

On Thu, 2019-10-24 at 12:34 +0300, Adrian Bunk wrote:
> On Thu, Oct 24, 2019 at 09:15:01AM +0100, 
> richard.purdie at linuxfoundation.org wrote:
> > The cmake change makes python visible from HOSTTOOLS. That isn't
> > wrong
> > as such, it is a change in behaviour. If recipes don't set python
> > enabled/disabled explicitly, there is some fallout from that. I'd
> > say
> > that is a bug in those recipes which aren't giving explicit
> > configuration to dependencies though.
> 
> The problem is not about enable/disable, it is more about not
> explicitly selecting the python version.
> 
> For the affected libiio the python2 -> python3 change of the python 
> bindings last week [1] was basically:
> 
> -inherit cmake pythonnative systemd
> +inherit cmake python3native systemd
> 
> This is very fragile, and I would consider it expected that either
> the old or the new case will break in some way when both python2 and
> python3 are available during the build.

That isn't the complete story. We changed the search path in master:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1

which then meant libiio found the wrong python as "python" in PATH
became py2.

As you say, it doesn't specifically declare which python it wants so
things changed.

I admit I'd misread the recipes, both for the upgrade and
enable/disable, I should know better. I think this kind of proves my
point about trying to push more work onto people who are already
overworked though.

The key questions:

* is that OE-Core change is correct?
* should this recipe be more explicit about its configuration?
* are there other places this problem has been introduced?
* who is responsible for fixing any further issues?

While we remember we should document this for the 3.1 migration guide
at the very least.

Cheers,

Richard