Order of layers in BBLAYERS

[Heinisch, Alexander]

Hi,

 

While upgrading from 4.5 to 4.7 I found a problem with ordering of layers similar

to the ones described here [1] and here [2]

 

[1] https://github.com/siemens/kas/issues/36

[2] https://github.com/siemens/kas/issues/130

 

 

Namely, the ordering of repos/layers changed (already in 4.6)

and, thus, the resulting `BBLAYERS` in the `build/conf/bblayers.conf` changed.

 

In one of my layers we are using config files overriding/masking the ones from

upstream layers. While that's not an issue with recipes (`BBFILE_PRIORITY_*`)

bitbake only respects those prios for recipes. While still maintaining search order

for configs and other files based on `BBLAYERS`.

 

Since the ordering changed this, directly affected one of my machine configs.

I know the fundamental issue I had was not appearing up to now just by

“coincidence”, but it triggered me doing some investigation.

 

Up to 4.5 kas ordered by path appended to `BBLAYERS`.

There was an attempt to mitigate the issues (linked above) done by Felix:

https://github.com/siemens/kas/commit/ecf5827b0769e3fcacb8b7ff7a73659ee6dc39ab

This orders the repositories and layers based on their name (=id if not specified)

Thus, one can force order by adding `name` to the repositories.

 

Unfortunately, this has two major drawbacks:

1. Changing the name of the repositories, also impacts the folder in which they

are cloned, which seems not ideal to me.

 

2. There is no way to specify order for layers.

e.g. for isar many projects use meta and meta-isar ending up in

```

${TOPDIR}/../work/isar/meta \

${TOPDIR}/../work/isar/meta-isar"

```

thus config from meta precedes config from meta-isar,

which imo is not what users expect!

 

Some quick thoughts how to make the ordering forcible without having to care about

the path we are cloning repos to:

 

1. preserve the order as it was in the kas file(s)

I had a quck discussion with Felix offline, he mentioned that this is not an option.

Since I could not understand why, I put it here for clarification.

 

2. Use the repo dictionaries id to force order. This allows for specifying the

clone directory by setting name while allowing to add ordering by changing the

repository id. While implementation effort is very low, this does not help with

layers. -> not an option

 

3. Adding priority/ordering to repo and layer dictionary.

This would solve the problem for repo and layer, but requires to maintain the

ordering manually, especially when pulling in kas files from other repos.

 

4. Adding priority/ordering derived from the layers `BBFILE_PRIORITY_*`

That way, config precedence would match the precedence order of recipes.

 

What are your thoughts?

 

BR Alexander

[Konrad Weihmann]

If you want to keep the original name of the checkout directory you should combine it with path.
E.g.

meta-foo:
   name: 2000
   path: meta-foo

meta-bar:
   name: 1000
   path: meta-bar

will create

meta-foo
meta-bar

directories with a bblayers.conf

meta-bar
meta-foo

order.

Like this you are in full control over names and order.
Name will end up being somehow exactly like this priority/id thing that you were describing.

[Jan Kiszka]

@Alex: please avoid html on mailing lists.

On 29.05.25 08:16, Konrad Weihmann wrote:
> If you want to keep the original name of the checkout directory you
> should combine it with path.
> E.g.
>
> meta-foo:
>    name: 2000
>    path: meta-foo
>
> meta-bar:
>    name: 1000
>    path: meta-bar
>
> will create
>
> meta-foo
> meta-bar
>
> directories with a bblayers.conf
>
> meta-bar
> meta-foo
>
> order.
>
> Like this you are in full control over names and order.
> Name will end up being somehow exactly like this priority/id thing that
> you were describing.

This addresses the repo (re-)naming, right. But it only helps with
ordering in case of single-layer repos because path refers to a repo,
not always to a layer. In case of multi-layer repos, ordering of their
layers remains name-based, thus not under control of the kas config author.

We could address that in theory by adding some sorting key also for
layers. But I'm still not convinced if this is actually an official
property of BBLAYERS. It's not specified (in contrast to
BBFILE_PRIORITY), and I'm not a fan of making something official via kas
that is actually not official from bitbake POV.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Heinisch, Alexander]

On Thu, 2025-05-29 at 16:49 +0200, Jan Kiszka wrote:
> @Alex: please avoid html on mailing lists.

sry for that!

That's what I mentioned as approach 2 -> not an option

> We could address that in theory by adding some sorting key also for
> layers. But I'm still not convinced if this is actually an official
> property of BBLAYERS. It's not specified (in contrast to
> BBFILE_PRIORITY), and I'm not a fan of making something official via
> kas
> that is actually not official from bitbake POV.

While there is no spec for that, specifying the order per layer
for BBLAYERS is generic enough imo. It does not imply any semantics
added by kas, just specifying the order in the BBLAYERS variable. That
way it is still in the responsibility of bitbake only how it treats the
order of entries (if at all). Thus, adding sorting keys / order to the
layer entries in the kas file is similar to specifying BBLAYERS =
"<list of layer>" in the config sections, but adapts automatically when
adding new repos/layers.

>
> > > 1. preserve the order as it was in the kas file(s)
> > > I had a quck discussion with Felix offline, he mentioned that
> > > this is not an option.
> > > Since I could not understand why, I put it here for
> > > clarification.

Clarification needed.

> > >
> > > 2. Use the repo dictionaries id to force order. This allows for
> > > specifying the
> > > clone directory by setting name while allowing to add ordering by
> > > changing the
> > > repository id. While implementation effort is very low, this does
> > > not help with
> > > layers. -> not an option

-> Not an option (same conclusion as in discussion above)

> > >
> > > 3. Adding priority/ordering to repo and layer dictionary.
> > > This would solve the problem for repo and layer, but requires to
> > > maintain the
> > > ordering manually, especially when pulling in kas files from
> > > other repos.

See discussion above

> > >
> > > 4. Adding priority/ordering derived from the layers
> > > `BBFILE_PRIORITY_*`
> > > That way, config precedence would match the precedence order of
> > > recipes.

Introduces unexpected/undocumented ordering semantics. Right now
BBFILE_PRIORITY_* only applies for recipes not for config files aso.
-> Not an option


BR Alexander

[MOESSBAUER, Felix]

IMHO it does not really matter if it is specified in bitbake, as
usually (without kas), the entries in bblayers are under full user
control. Given the various requests regarding this topic also shows
that it is at least not uncommon to require a specific order.

I propose to add the interface as discussed in [1] (layer: prio [0-
99]), but use priorities between 0 and 99, whereby higher means
included first.

[1] https://github.com/siemens/kas/issues/36#issuecomment-2612537945

Felix

>
> Jan
>
> --
> Siemens AG, Foundational Technologies
> Linux Expert Center

--
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

[Jan Kiszka]

It does matter: If bitbake said, "don't rely on that ordering thing,
it's not guaranteed", kas will do nothing to support that nevertheless.

>
> I propose to add the interface as discussed in [1] (layer: prio [0-
> 99]), but use priorities between 0 and 99, whereby higher means
> included first.

I won't merge anything before we clarified that upstream. Who would like
to drive this?

[MOESSBAUER, Felix]

There is a long discussion about this topic on the bitbake ML, but
unfortunately without ANY agreement (not even to document the current
behavior) [1]. TL;DR: The order should not matter, but sometimes it
does due to poorly written layers / recipes. Further, there are too
many knobs to influence the precedence.

>
> >
> > I propose to add the interface as discussed in [1] (layer: prio [0-
> > 99]), but use priorities between 0 and 99, whereby higher means
> > included first.
>
> I won't merge anything before we clarified that upstream. Who would
> like
> to drive this?

Agree. Given the ML thread from above, I also propose to simply offer
nothing until it has been clarified upstream.

OT:

The layer handling code in kas is also not well modeled (a big enum
with magic values of different types, all meaning the same whereby
"null" means something else...) [2]. It is documented, but its
definitely not nice. I'm wondering if we want to clean this up and
already issue deprecation warnings in kas 4.8.

[1]
https://lists.openembedded.org/g/openembedded-architecture/topic/crazy_proposal_drop/104180197
[2]
https://github.com/siemens/kas/blob/b6744655ba83f764b6d6d20a766e1a7a91f537f1/kas/schema-kas.json#L258

Felix

>
> Jan

[Heinisch, Alexander]

On Mon, 2025-06-02 at 12:02 +0200, Jan Kiszka wrote:

Layer priority is little missleading. In essence it just specifies the
order the bblayer.conf files are parsed. Probably what most people
would assume is layer priority wrt. config files and bbclass files
priority/search order. And this is solely given by the BBPATH variable
oftentimes/mostly (arbitrarily) extended in the bblayer.conf file.

In general we already see 2 main strategies followed in bitbake for
various types of files: BBFILE_PRIORITY for .bb and .bbappend, BBPATH
for all other files.
While BBFILE_PRIORITY gives a global order BBPATH depends on order in
BBLAYERS as well as how the bblayers.conf of each layer looks like.

>
> I won't merge anything before we clarified that upstream. Who would
> like
> to drive this?

You are right, putting an order for BBLAYERS potentially hides the root
cause for the issue itself. I think the actual behavior is understood,
so we "just" need to clarify the why and if overwriting config and
bbclass files in different layers is considered an anti-pattern, and if
so, why.

>
> Jan
>

BR Alexander