Em qua., 16 de jun. de 2021 às 02:08, Chen Qi <Qi.Chen@...> escreveu: I really like the === proposal. -- Otavio Salvador O.S.

Yes, that's a fair point. As you say, I kind of have the sense that our classes are drifting towards being more like classes in a "real" programming language, complete with an actual API, and

On 06/15/2021 06:29 PM, Richard Purdie wrote: I think so. 1) In the view of compatibility, it's acceptable. Before the change, we have: _remove >

That is a good summary, yes. It certainly could be a solution to the problem but I worry that having variables that users should touch and not touch and variables shadowing other variables is going

<mark.hatle@...> wrote: I skimmed some of the thread so may have missed a detail... but if the initramfs recipe wants to forcefully over-ride a value of IMAGE_FSTYPES set by a BSP,

There is more then once I thought it would be good to add a flag for some sort of variable type. Specific for this reason. "This variable is a MACHINE variable, this is a DISTRO variable, this is a

Thanks for the background, I understand the issue a bit better now. It seems fairly apparent that what's wrong here isn't fundamentally an issue with OVERRIDES, it's more that the semantic layering

I'm going to intentionally avoid using "image" as gets overloaded I think. This is because an initramfs can be more than one of: - The only filesystem container we create for a MACHINE - A filesystem

I've hit this issue in the past (different context, but I believe the same issue). What I end up doing is (in the initramfs) is effectively: OVERRIDES .= ":ramfs" IMAGE_FSTYPES_ramfs = "cpio" doing

Ah! Just slightly before my starting time with the project :) OK, thanks. Pondering time... -- Tom

Consider this example where the BSP sets: IMAGE_FSTYPES = "tar" IMAGE_FSTYPES_somemachine = "ext4" INITRAMFS_FSTYPES = "cpio" OVERRIDES = "${MACHINE}" then the initramfs image recipe

I haven't tried to obscure it, the machine name was in the original email but I guess not everyone remembers Zarus models names like I do! :) The BSP layer in question is meta-handheld,

Hi All, I've been using bitbake for >5 years now, however I do not understand the nature of the problem at all. Could you clarify what the problem is i.e. what's the difference between these

Thanks for all the details here. Since this is stemming from a specific BSP, I think at this point it might be good to share what exactly it is, and it wouldn't be seen as "shaming" that BSP at this

I should apologise for being a little grumpy in some of my replies, it is fair to say that everything is getting to me a little as continual build failures and being continually asked for reasoned

Think about this in the context of what the initramfs recipe is trying to do. It doesn't care about IMAGE_FSTYPES, it cares about INITRAMFS_FSTYPES only. If the BSP wants to change anything they'd

Hello Richard, Em ter., 15 de jun. de 2021 às 07:29, Richard Purdie <richard.purdie@...> escreveu: Having it resetting it might fix this use case but what if the _collie use case is

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

Well, it seems like an ok thing for a BSP to do to me. There are probably  other ways it could be done, sure. No, I don't see how that helps. The issue in the email is an example of a general

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