Re: New assignment operator?


Richard Purdie
 

On Tue, 2021-06-15 at 13:55 +0200, Phil Blundell wrote:
On Tue, Jun 15, 2021 at 11:29:01AM +0100, Richard Purdie wrote:
  a) is another assignment operator a good idea?
I'm not terribly convinced it is. If the problem is that there's no
way to clear the OVERRIDES, maybe we should just have a new verb to
do that specifically rather than a new assignment operator that
ignores them.
Sure, but then you just end up writing:

unset IMAGE_FSTYPES
IMAGE_FSTYPES = "x"

The assignment wouldn't ignore them, it really would remove them from 
the knowledge of the variable. The difference is basically the difference 
between:

setVar("IMAGE_FSTYPES", val, parsing=True)
setVar("IMAGE_FSTYPES", val, parsing=False)

since behind the scenes bitbake has two different behaviours for
setVar, "parsing" mode and non-parsing mode. This was after we learnt
we had two different expectations from setVar in anonymous code and
from parsing metadata.

So we'd be adding an operator that behaves like the default setVar().

Ultimately though this particular example just seems like a case
where it's possible for a carelessly-written BSP to make life
difficult for its users. I don't think this is the only such,
and I'm not sure a new assignment operator would necessarily solve
the general case.
It would solve a general case problem of not being able to actually 
reset a variable outside anonymous python. I'm also not sure I'd say
the BSP was carelessly written. It used overrides, we recommend and 
support them, it just then interacted badly with the way a recipe was
written (which has been copied to multiple places).

Adding more and more special operators that defeat each other seems
like it's just going to result in a perpetual arms race.
Maybe, maybe not. The initramfs recipe can't really express what it
needs/wants to do with the current syntax.

If we add
a new !=! operator then, BSP authors being as ingenious as they are,
they'll start using that all over the place and you suddenly won't
be able to override anything any more. Then we'll need a new and
even more powerful OVERRRRIDES that can't be suppressed, and we'll
be back where we started :-)
Maybe we make it a non-conf context operator?

I don't know. I think it doesn't matter what I suggest these days,
the answer will be "no, it is already complicated enough". As such
we therefore accept nothing will change.

I put together the proposal as I don't think the BSP or the image
recipe are really at fault here and I can't give them a good way
to handle the situation.

Cheers,

Richard

Join openembedded-architecture@lists.openembedded.org to automatically receive all group messages.