Thanks Peter, this is the argument that I tried but clearly failed to make.
How about I make a patch that sets things to = across all of poky, give it to a-full build and then we can see what, if anything, falls out? Whatever the eventual plan may be, this is an experiment worth doing. Alex On Fri 22. Dec 2023 at 0.55, Peter Kjellerstedt <peter.kjellerst...@axis.com> wrote: > > -----Original Message----- > > From: openembedded-architecture@lists.openembedded.org <openembedded- > > architect...@lists.openembedded.org> On Behalf Of Joshua Watt > > Sent: den 21 december 2023 16:57 > > To: Richard Purdie <richard.pur...@linuxfoundation.org> > > Cc: OpenEmbedded Architecture <openembedded- > > architect...@lists.openembedded.org> > > Subject: Re: [Openembedded-architecture] Weak PACKAGECONFIG removal > > > > On Thu, Dec 21, 2023 at 6:13 AM Richard Purdie > > <richard.pur...@linuxfoundation.org> wrote: > > > > > > 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. > > > > This one seems a reasonable approach worth exploring. I think > > "append-list" and "remove-list" might make more sense; I'll poke > > around and see if I can at least prototype this to see how it looks in > > practice > > > > > > > > > > Like I said at the start, these are just random half baked ideas I've > > > been wondering about... > > > > > > Cheers, > > > > > > Richard > > For what it's worth, my vote would be on 4), and using = as the new > standard. > That is what we do in all our own recipes. > > It is a simple change (simple to understand, that is), which does not > introduce any new special syntax or new variables. I do not think it would > actually break many (any?) existing layers, at least no worse than many > other > changes that have been introduced over the years. And the reason for that > is > that any layer that is manipulating a recipe's PACKAGECONFIG today would > either have to do that through an override in a .conf file, and that would > continue to work, or through a bbappend, and that too would continue to > work since the only options today are either full a replacement using > PACKAGECONFIG = "..." or :append/:remove, both of which would also > continue > to work. > > //Peter > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1892): https://lists.openembedded.org/g/openembedded-architecture/message/1892 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] -=-=-=-=-=-=-=-=-=-=-=-
