Re: New assignment operator?


Petr Nechaev
 

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 lines:

IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
VAR_A = "${VAR_B}"

In both cases .. it seems .. I am prepared that VAR_C = "${VAR_A}" won't expand to VAR_B due to overrides, appends etc.  What is special about initramfs image?  Is there any special meaning to IMAGE_FSTYPES variable? 

If not ... are we trying to introduce a language feature to solve one particular problem of a specific image?

---
Petr


On Tue, Jun 15, 2021 at 4:38 PM Tom Rini <trini@...> wrote:
On Tue, Jun 15, 2021 at 02:29:16PM +0100, Richard Purdie wrote:

> 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 arguments for 
> saying "no" to things is wearing me down. We have bugs in many core pieces
> of the system (pseudo, patchelf, prelink, ltp, oeqa, devtool, eSDK and so
> on) and currently it feels like I'm the only person with the domain 
> knowledge to try and attempt to look into them. This shouldn't ripple 
> out into emails though.
>
> The context of this issue is probably important and I didn't really 
> mention it.
>
> I've been asked about a "bitbake bug" a lot on irc recently and asked
> for help in trying to resolve it. I spent quite a bit more time than 
> expected (on my weekend) trying to understand the issue and it wasn't
> the issue as reported but a lot more subtle. In the emails here I've
> spelt out the problem but the way it becomes exposed to the end user
> is a lot more insidious.
>
> I don't think the BSP was doing anything wrong using a MACHINE override
> on a variable. The initramfs recipe was also not really doing anything
> wrong trying to set the fstypes to the initramfs ones.
>
> The interaction between the two things is rather unfortunate and in this
> case the BSP maintainer could not see why it was breaking and even me, with
> a few years experience with bitbake couldn't immediately understand what
> was wrong or how my own fix was going to break.
>
> Even now I think broken "fixes" are being spread around in attempts to try
> and work around the issue which swap on machine's breakage for another 
> (collie works but qemux86 using image-live then doesn't).
>
> It does worry me a lot that the issue is so obtuse to debug and that whilst
> we can patch this one up, someone else can/will hit it again. The potential
> to hit it with some other variable also remains. I don't like issues that
> few people can "see" into and understand.
>
> For that reason I would like to change the initramfs recipe somehow to
> improve usability and ensure people don't hit this. Right now I can't see
> any way to do that other than to say "don't do that". I can't even add
> anything to tell the user there is a problem. This was the spirit the
> proposal was born from. I understand why people don't like any new operator,
> I'm not thrilled either but what I'm not seeing are alternatives to improve 
> usability :/.

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 point as it's
exposed a rather, as you note, obtuse problem.

I have another "could we just ..." idea on this, but I could answer that
myself maybe with the exact problem laid out.

--
Tom



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