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

Attachment: signature.asc
Description: PGP signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1235): 
https://lists.openembedded.org/g/openembedded-architecture/message/1235
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to