Re: New assignment operator?


Richard Purdie
 

On Tue, 2021-06-15 at 17:10 +0200, Phil Blundell wrote:
On Tue, Jun 15, 2021 at 02:29:16PM +0100, Richard Purdie wrote:
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 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 (in the generic sense of
the word, not meaning OE layers) has just gone wrong with IMAGE_FSTYPES. So
you have this one variable that, on one hand, is a user-tweakable knob that
they can set to say "this is the type of filesystem image I want to generate
for my particular machine", and on the other hand is part of this shadow
interface contract between the initramfs code and the image-construction
backend. meta-zaurus is trying to change the first one and accidentally
clobbering the second one and I agree it can't really do much better with
the current infrastructure.
That is a good summary, yes.

So, the simplest way of fixing the immediate problem seems to be to separate
the two things out: make image.bbclass look at some new variable
(IMAGE_GENERATE_FSTYPES or something), teach the initramfs code to set that
variable rather than IMAGE_FSTYPES, and provide a soft default of
IMAGE_GENERATE_FSTYPES ??= ${IMAGE_FSTYPES}.

In the more general case it seems like any given variable ought to be
classifiable as something that's either settable by the user configuration
(including the BSP in that) or that is set by some other class in oe-core,
but I think we ought to try to avoid having variables that fall into both
groups.
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 to get complex rather quickly, even when you just
consider how you document or "enforce" it. Do we want to encourage what
could become many more intermiediate variables? It does sound like we're 
effectively starting to write class "functions" with a list of variables
they operate on which may or may not be a good thing depending on how 
common it became.

From descriptions from others it sounds like people have creatively worked
around this kind of issue with stronger overrides which I'd not considered
and would also work, it is just a little ugly in a different way. I'd consider 
use of the forcevariable override in oe-core a metadata failing (much like 
I view _remove similarly in core).

Which does bring us back to whether adding something allowing the initramfs 
recipes to do the right thing would be a better solution? An initramfs 
class to abstract it whatever we do may also be worth considering but is
tangential.

Cheers,

Richard

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