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