On Tue, Jun 15, 2021 at 8:48 AM Mark Hatle
<mark.hatle@...> wrote:

On 6/15/21 10:10 AM, Phil Blundell via lists.openembedded.org 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.

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.

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 recipe variable, this is a class
variable, etc." Of course identifying what we're doing and warning may not be
so easy, but it could help. Along with this identify where an override is being
used, if it's a MACHINE override it probably shouldn't be in a DISTRO file for
instance.

The case where I was curious if we could do something like this very different.
I saw MACHINE files setting what are effectively distribution features, and
distro.conf files having machine overrides in them.

All tend to lead to problems like this in the long term, variables that get set
and can't easily be "unset".

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, then isn't the existing _forcevariable
over-ride the way to do that?