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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1231):
https://lists.openembedded.org/g/openembedded-architecture/message/1231
Mute This Topic: https://lists.openembedded.org/mt/83552628/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
