Re: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2026-03-17 at 17:41 +0000, Peter Kjellerstedt wrote:
> 
> I think one of the biggest problems here actually is the freedom 
> provided by the current solution for how layers are added and 
> configured, and I believe we actually want to make it much more 
> rigid. Which of course will make people scream (possibly 
> including myself).

Agreed, there are just too many options currently. Anything we choose
to remove or restrict will upset someone though.

> 
> I would love to see an addlayer command (or something similar) 
> that would hide all the gory details of layer priorities, 

Oddly enough, somewhere I have a patch which does add an addlayer
directive so it was something I already experimented with.

The sticking point was that I really wanted to just drop the layer
priority part of the code and I couldn't face the number of complaints
that might generate.

> dependencies, and making sure it is consistent when applying 
> bbappends and the order .conf files are read, etc, and avoids 
> problems with different layers having their own ideas about how 
> to do things. Unfortunately, I do realize this is an enormous 
> job, and getting all the details right will probably be near 
> impossible, especially as everyone undoubtedly have their own 
> ideas about how layer configuration should be done (I know I do). 
> And, unfortunately, I also have a pretty good idea of who would 
> have to do most work to make anything like this happen.
> (I have a feeling I'm not selling this idea very well... ☹)

The last time I touched this issue, I got into a lot of trouble very
quickly. It needs time available to handle all that correctly and it
simply isn't something I've had.

> Another thing I would like to see is that the order in BBLAYERS 
> does not matter. Instead, the layer dependencies should determine 
> the order, pretty much like how the task dependencies decide the 
> order the tasks are executed. Unfortunately, I do not know if 
> even this is possible, or if my view of how the layers are 
> configured is too simple.

I'm certainly want to explore that idea. We need to work out what
issues people may run into that couldn't be solved in that case and
whether we're prepared to accept those compromises.

> And if I may be a bit adventurous, I could even see the BBLAYERS 
> variable being removed altogether (or at least not used as input), 
> and instead be replaced by, e.g., a drop directory where you 
> create links to the layers you want to use in a specific 
> configuration. Then adding/removing a layer to the build is just a 
> matter of adding/removing a link, which is easily done by tools 
> like bitbake-setup, bitbake-layers, kas, repo, or even just ln -s, 
> without having to manipulate an actual configuration file, which 
> is always error prone.

I think BBLAYERS as a list of places to look isn't the main issue at
this point but I appreciate the idea.

Cheers,

Richard