On June 15, 2021 10:29:01 AM UTC, Richard Purdie
<[email protected]> wrote:
>We have an interesting problem with initramfs images. They do something like:
>
>IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
>
>which looks innocent enough until a BSP does:
>
>IMAGE_FSTYPES_collie = "xxx"
>
>where collie is MACHINE, hence an override which causes confusion as
>the value of INITRAMFS_FSTYPES is never used for that machine.
>
Is that an issue that needs to actually be fixed? This is just another example
of weird BSP given by vendors to me, right?
Resetting IMAGE_FSTYPES_collie to INITRAMFS_FSTYPES should be enough to fix
this issue right?
>This is a long standing issue where in standard metadata, there is no way
>to undo an override (or append/prepend/remove).
>
>I tried to be clever and did:
>
>python () {
> d.setVar("IMAGE_FSTYPES", d.getVar("INITRAMFS_FSTYPES"))
>}
>
>and if you do that before the image class inherit (since anon python is
>executed in the order it is defined), it nearly works. It doesn't work
>with live images as IMAGE_FSTYPES is expanded for class inherits before
>the anonymous python executes.
>
>I also wondered about:
>
>IMAGE_FSTYPES := "${INITRAMFS_FSTYPES}"
>
>but that doesn't clear overrides either. In fact I can't actually see
>a way to do it other than some horrible thing like:
>
>def myfunc(d):
> d.setVar("IMAGE_FSTYPES", d.getVar("INITRAMFS_FSTYPES"))
>
>DUMMYVAR := "${@myfunc(d)}"
>
>Yes, we could do that but I don't think we should.
>
>I wondered about making := clear existing overrides/appends/prepends/removes
>but then I wondered if we should have a new assignment operator which
>would do that (and also not force the value to be expanded). I mentioned this
>on irc and there were a few suggestions:
>
>IMAGE_FSTYPES =!! "${INITRAMFS_FSTYPES}"
>
>IMAGE_FSTYPES !=! "${INITRAMFS_FSTYPES}"
>
>IMAGE_FSTYPES *:= "${INITRAMFS_FSTYPES}"
>
>IMAGE_FSTYPES :=* "${INITRAMFS_FSTYPES}"
>
>The questions are
> a) is another assignment operator a good idea?
I'm not sure the issue explained in this mail is enough to warrant a new
assignment operator.
I can already see vendors abusing this by always using this new operator
instead of using overrides or whatever.
This would be even less fun to support on IRC or mailing lists.
Also... As opposed to other operators, what would happen if you use the
following: IMAGE_FSTYPES_collir *:= "whatever". What would be the meaning and
behavior, it might warrant a different handling compared to other operators to
forbid any override (and append, prepend, remove).
> b) if so, which form?
>
Totally unbiased. The last two 😁
It highlights that like := it is an immediate assignment operator. The asterisk
indicates that it will apply to "everything".
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1228):
https://lists.openembedded.org/g/openembedded-architecture/message/1228
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]]
-=-=-=-=-=-=-=-=-=-=-=-
