FWIW, I think that the right way out is to convert all recipes to use = for default PACKAGECONFIG sets., and drop the confusing ?=/??= stuff. What we should offer is a sane default, and an easy, obvious way to add and subtract from it. Is there a real need to completely reset the overall value?
If you disagree, please speak up now. Alex On Tue, 19 Dec 2023 at 21:52, Christopher Larson <[email protected]> wrote: > > I've long felt the use of ??= was not ideal, as it's prone to breakage. A > user unintentionally using += will blow away the default entirely, which is > almost certainly not what they intended, and if they do it in local.conf, > it'll do so for every recipe they build. > > On Tue, Dec 19, 2023 at 1:46 PM Alex Kiernan <[email protected]> wrote: >> >> On Tue, Dec 19, 2023 at 8:20 PM Joshua Watt <[email protected]> wrote: >> > >> > All, >> > >> > This message is to start a discussion about removal of undesired >> > recipe PACKAGECONFIG options. >> > >> > Background: >> > Since the dawn of using OpenEmbedded as part of my day job, we've used >> > meta-gplv2 to avoid GPLv3 code in our products. However, I recently >> > decided that it was past time to excise this particular wart from our >> > code base, so I've been looking at how to do this. Ideally, I would >> > like to make it some sort of shared .inc file that can be included and >> > we can all collaborate on to make it easier for this fairly common use >> > case. >> > >> > >> > One of the major things that comes up frequently is that the >> > PACKAGECONFIG for a recipe needs to be modified to remove some >> > incompatible flag from the default options. This particular option is >> > not very simple though, because most recipes set PACKAGECONFIG using >> > the "deferred weak" assignment, as in `PACKAGECONFIG ??= "foo bar"`. >> > Because of this, any operation that attempts to modify this variable >> > will overwrite the default; commonly one might like to do something >> > like `PACKAGECONFIG:remove = "foo"`, but since this happens before >> > weak assignment, the result is an empty string instead of just the >> > value "bar". >> > >> > I've come up with a number of solutions for this, but I'm unsure which >> > ones make sense to explore as long term options for the project: >> > >> > 1) Do nothing and respecify the complete set of PACKAGECONFIG options >> > when overriding. This basically means instead of PACKAGECONFIG:remove >> > = "foo", you would explicitly set to the remaining items like >> > PACKAGECONFIG = "bar". If no other solution is appealing, this is >> > probably fine, and what I'll do. The main reason I don't like this is >> > because package configs are frequently added to recipes and it's >> > annoying to keep them in sync (mostly, because I'm lazy :) ). >> > >> > 2) Add a PACKAGECONFIG_REMOVE variable that is evaluated by the >> > package config code and causes it to ignore any matching items. This >> > one is pretty easy in the packageconfig code, and I think users would >> > find it pretty easy to understand. The downside is that it's very >> > specific to packageconfig; there are other variables that probably >> > would want similar treatment, but it may not make as much intuitive >> > sense to do for them also (e.g. IMAGE_FEATURES, DISTRO_FEATURES). >> > Also, much like :remove, you wouldn't want this used in actual >> > recipes; it should only be set by end users. >> > >> > 3) Change the order of weak assignment vs. remove. This one is a >> > little trickier but the idea is that if ??= and :remove don't make >> > sense in their current order, flip around the order of evaluation so >> > that it does make sense (e.g. apply :remove after ??=). I'm not sure >> > how easy this would be and if it could be done all the time, only when >> > a variable was a "list", or some other criteria >> > >> > 4) Stop using ??= for default PACKAGECONFIG. I'm not sure the history >> > as to why it's ??=, but switching it to ?= (or maybe even =) would >> > solve the problem because then :append, :remove, +=, et. al. would >> > work as expected. The only case I can think of where this wouldn't >> > work is if a bbappend was doing a ?= to set a completely new set of >> > default PACKAGECONFIG flags; I'm not sure why that would be necessary >> > though. Are there any other cases I've not thought of? >> > >> >> At some point I picked up the strong message that this was the >> preferred approach and have used it since (and it makes sense to me). >> For the set of layers I have in my default poky testing build there's >> 490 which have ??= and 146 which have ?=, so clearly a majority, but >> not a completely overwhelming one. >> >> > 5) Add "filters" to variables. The basic idea behind this one is that >> > variables would get a new flag called "filter" where pipelines of >> > limited expressions could be constructed. These filter expressions >> > would be applied after the final value of the variable (and thus, >> > after weak assignment). For this specific case, this might look >> > something like: `PACKAGECONFIG[filter] = "remove(v, 'foo')"`. This is, >> > admittedly, a _very_ general solution for this particular problem. >> > However, this concept has been discussed in other contexts such as >> > multilib and BBCLASSEXTEND, so if it is something that would help >> > there, this problem could leverage that solution also. If you want a >> > peek at what this might look like, there is a jpew/bb-filters branch >> > in poky-contrib >> > >> > >> > If you have any thoughts or other possible solutions, please let me know. >> > >> > Thanks, >> > Joshua Watt >> > >> > >> > >> >> >> -- >> Alex Kiernan >> >> >> > > > -- > Christopher Larson > [email protected], [email protected], [email protected] > Principal Software Engineer, Embedded Linux Solutions, Siemens Digital > Industries Software > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1885): https://lists.openembedded.org/g/openembedded-architecture/message/1885 Mute This Topic: https://lists.openembedded.org/mt/103269425/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
