On Tue, Jun 15, 2021 at 8:48 AM Mark Hatle <[email protected]> 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?
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1244): https://lists.openembedded.org/g/openembedded-architecture/message/1244 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]] -=-=-=-=-=-=-=-=-=-=-=-
