Some parameters are meant to be used only when placed inside local.conf or similar configuration file (ex: distro.conf) However there is no mechanism that can help the person trying to use a recipe, to figure out that the parameter was misplaced (ex: inside a .bb .bbclass or .bbappend file). Worse, things can change over time, because a recipe is modified, yet there is no way to detect that was previously ok is now a bug. As example, here's an excerpt from [1] -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- > In such below sentence from local.conf.sample is wrong or I missing > something here? > > *# NOTE: You can set INITRAMFS_IMAGE in an image recipe, but* > *# INITRAMFS_IMAGE_BUNDLE can only be set in a conf file.* It would seem that this is no longer correct - perhaps it was true in an older version. kernel.bbclass (which is inherited by all kernel recipes) reads both of these variables, so they do both need to be set at the configuration level. We should update the comment. -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- If there was some way to either explicitly or implicitly declare where a parameter should be configured (recipe vs conf), that would allow bitbake to generate at lest a warning ,if not an error. Ex: - explicit: let the recipe using a parameter declare where it should come from - implicit: use a prefix (CONF_xxxxx) for parameters that belong to conf files [1]: https://lists.yoctoproject.org/pipermail/yocto/2015-April/024610.html
There's very few variables that *need* to be set in local.conf vs distro conf vs recipe (I can't think of anything apart from the obviously recipe-specific instances such as FILES), and in fact a large number of variables are explicitly available to be set in all three (user customisations, distro defaults, recipe overrides). Personally I feel that context is sufficient: don't set FILES in local.conf, don't set DISTRO_NAME in a recipe, etc; and where it isn't then the documentation should clarify. From an implementation point of view, there's no difference between distro/local/recipe beyond filename, whether a copy has been made, and parse order, so I think this would be distinctly non-trivial to implement.
I obviously disagree with the statement that the context is sufficient, otherwise I would have not created the issue report :-) Improving the fine manual is ok, but it is not particularly developer friendly, after having done so, to just reply RTFM. I can understand if the answer is: "improving this has a low ROI" However I do not understand why this would be a non-trivial change. Wouldn't it be sufficient to search for the fingerprint part of he string ()in the example, CONF_ and compare it against the type of file where th CONF_xxx entry is used?
(In reply to comment #2) > However I do not understand why this would be a non-trivial change. > Wouldn't it be sufficient to search for the fingerprint part of he string > ()in the example, CONF_ and compare it against the type of file where th > CONF_xxx entry is used? If we're happy to accept a complete API break as large numbers of variables change their name, sure. Not sure that's a good tradeoff though.
It depends on how the change is introduced. What you describe is a hard change. If it was made available as opt-in feature, new/converted recipes could use it, while others wouldn't be affected. All I can say as a user, is that it feels unnatural to have 3 different types of file where to put basically the same type of assignment, without (afaik) a simple way to figure out what is set where. The example I gave in the issue report seems to agree with my feelings. I do not particularly care that it is done in the way I proposed, if the change I proposed is unfeasible/hard to implement and the same improvement can be achieved better/more easily through automated means. Adding more documentation will eventually turn the mega manual into a giga manual, but I doubt it's reasonable to expect the user to remember it all. Not if the goal is to provide a pleasant experience.
If a variable can go in multiple places then there tends to be a good reason for that: is it distro policy, recipe configuration, or user overriding. Other variables have clear scope: RDEPENDS for example is recipe-specific. I don't see adding a naming convention or metadata being sufficiently useful to warrant the impact.
(In reply to comment #5) > If a variable can go in multiple places I do not know how it has come to this, when the request was about the opposite: (In reply to comment #0) > Some parameters are meant to be used only when placed inside local.conf or > similar configuration file (ex: distro.conf) > > However there is no mechanism that can help the person trying to use a > recipe, to figure out that the parameter was misplaced (ex: inside a .bb > .bbclass or .bbappend file).