A number of upstream git repos we build from are transitioning "master" branches to "main" branches. They're doing this and removing the old name. The scale of the problem this causes us is only just

I realise now that this will break for instance the inclusion of distro conf's from additional layers. Jacob

Here is a crazy idea: merge oe-core/meta/conf/bitbake.conf into oe-core/meta/conf/layer.conf, skip parsing a bitbake.conf altogether, and tell people to put the oe-core layer first in BBLAYERS. Then

Yeah that pretty much sums up the use cases - the question (and I guess tricky part) is about "no other wish is expressed" - and here, I think, something should be done, as it's not very intuitive for

Absolutely agree, I just see that it is harder to get rid of the append/prepend mechanism than the other. And I think it's not a tool issue per se - maybe it can be fixed by proper documentation -

That mechanism was introduced to solve a different and rather specific problem. It might be true that it isn't entirely intuitive, and there might be a bit of a lack of clear documentation describing

I'd like to add my 2 cents. While the complexity of operators may be somewhat confusing to new users or developers of the project, alongside with the order of file inclusion and different stages of

The example you mention with BB_HASHBASE_WHITELIST, it sounds to me like the underlying problem is that the order of file inclusion is not apparent to people, and not that there is any confusion about

I agree that there is a bit of a usability problem here, but I think this proposal is going in the wrong direction. It's really the _append/_prepend operators that have the uninituitive semantics and

Presumable this would behave like ??= though (?= as implemented is fairly flawed but so is ??= today, sadly). I have to admit if I was implementing layers again, I'd want to ditch a load of the older

Yes, I think we're talking about the same thing, its just a different way of thinking about it. I'm adding the challenge of trying to figure out what changes to existing behaviour we could consider to

I agree, having +=/=+ and friends operating against the default value would in general be the behaviour most people want/expect. The change in behaviour would be that "=" would no longer wipe

Maybe we could ask, what are the typical intentions behind those additions and removals and assignments? E.g. for DISTRO_FEATURES I can think of these: 1. Features A B C can be present in

I definitely think there’s a usability issue here. It’d be nice if +=/=+/.=/=. were recorded operations against the current or default value. Now that _append/_prepend/_remove are applied at

I totally agree that there is an usability issue. I myself have been confused for a long time about all these options and how they work together (or don't) and having now a hard time telling other ppl

I think DISTRO_FEATURES is (or at least was) behaving the same and that's probably what more people often tend to change in local.conf than BB_HASHBASE_WHITELIST. I always recommend to just use

I'm growing increasingly concerned about default value assignments in OE. The basic problem is people don't understand the way default values work and the mechanisms we do have don't let people do all

Sorry for the late notice. I figured out the calendar and added the item there and never announced anything. Moving forward, I' send dhort reminders and use the calendar to track

Hi, Back in 2009, regex support was added in ASSUME_PROVIDED: https://git.openembedded.org/bitbake/commit/lib/bb/taskdata.py?id=efb0474231ed286073a5a5904094320da8cab28d Looking at this now, I'm

I understand that this is an exception from regular stable process, but I believe the possible bad user experience was limited to only the users who update the layers incorrectly and the benefits and