[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Richard Purdie]

On Thu, 2017-05-11 at 08:54 +0200, Patrick Ohly wrote:
> On Tue, 2017-05-09 at 09:42 +0100, Richard Purdie wrote:
> > 
> > As you mention, there are some practicality issues associated with
> > that. If this means we need to improve the technology we're using
> > to
> > handle those issues I'd be very open to that.
> The override trick works to some extend, but there are cases where it
> does not work:
>       * addtask directive manipulating varflags ... and probably
>         more ...

I'd hope conditional addtask directives are comparatively rare and if
necessary, anonymous python would be acceptable in such cases.

varflags are trickier. I'd wondered about some kind of override syntax
for those but never found something that worked well as yet.

> Anonymous Python code can do some of that after a suitable if check,
> but that quickly becomes unreadable and unmaintainable.
> 
> I've come up with a more general approach that might be worth
> exploring
> further:
>       * copy the .bbappend content into a .bbclass
>       * in the .bbappend: inherit
>         ${@bb.utils.contains('DISTRO_FEATURES', 'foo',
>         'bar-my-former-bbappend', d)}
> 
> The downside is that these pseudo-classes clutter the "classes"
> directory. A natural place would be to put the .bbclass alongside
> the .bbappend file, but that doesn't work, and the failure shows that
> classes really are expected in a "classes" directory relative to the
> BBFILES:
> 
> ERROR: ParseError at .../recipes-devtools/bmap-tools/bmap-
> tools_%.bbappend:1: Could not inherit file classes/bmap-tools-
> deploy.bbclass
> 
> This is where some enhancement for the class mechanism would be
> useful.

I kind of see this as an "abuse" of classes, they're really meant to
encapsulate functionality and designed to be shared.


> Alternatively, and probably better, is to allow "require/include"
> statements without parameters. That is allowed for "inherit" already.
> Once it is allowed, we could have a bar-my-former-bbappend.inc
> alongside
> bar_%.bbappend and include that conditionally, similar to the class
> example above.

Therefore I think I like this a lot more. I'd certainly happily enhance
bitbake to handle this case, it shouldn't be too difficult and we did
this for classes already.

There is one drawback to both approaches though, which is that post-
parsing changes to the metadata won't have the desired effect. In
particular, BBCLASSEXTEND is post-parsing. This means a native override
on such a conditional file include may not work as you'd expect due to
the point the override gets established. Effectively you're doing an
expansion on OVERRIDES at the point you decide whether to include the
file.

This may or may not be a concern (and would affect classes and includes
equally).

> I've also considered whether keeping a single .bbappend file with
> some additional markup (think ifdef/endif) or some other extension
> where the if condition for including the .bbappend file gets
> specified. I'm undecided about both, as it is more intrusive.

I have wondered about this before. Overrides effectively are our
conditional markup and we've never found a syntax for this that felt
right...

Cheers,

Richard