On Tue, 2023-12-19 at 13:19 -0700, Joshua Watt wrote: > 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? > > 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.
I've some other 'random' thoughts. I've wondered about making the default value accessible in some way from the metadata and syntax. The most obvious is via a flag: PACKAGECONFIG[defaultval] = "somedefault" The downside is that flags are quite poor syntax wise compared to full variables, you can't change them with overrides for example so: PACKAGECONFIG:class-native[defaultval] = "somenativedefault" doesn't work. When you think about the bitbake internal ramifications of making flags support overrides, it makes me want to run away screaming so that isn't an option. That then brings me to: PACKAGECONFIG:defaultval = "somedefault" i.e. some kind of "special" override. How special it might need to me I've not really thought through. PACKAGECONFIG:defaultval:class-native = "somenativedefault" works. I did have some half proof of concept of this at one point, I think I maybe just ran out of time to work through all the corner cases and I think I got distracted by the override character change which was likely needed to make this even vaguely practical to implement. The other idea I've been wondering about is exposing the append/remove "lists" that variables have against them. You could do that with a flag like PACKAGECONFIG[appends] but the most common thing to want to do would be to remove items and we don't have a flag removal operator. I did also wonder about: PACKAGECONFIG:appends:remove = "XXX" PACKAGECONFIG:removals:remove = "XXX" as being special synax which would do something a little different. appends and append are very similar, perhaps too similar but the overall idea might be worth a bit of further thought. Like I said at the start, these are just random half baked ideas I've been wondering about... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1887): https://lists.openembedded.org/g/openembedded-architecture/message/1887 Mute This Topic: https://lists.openembedded.org/mt/103269425/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
