Re: [bitbake-devel] [PATCH RFC] parse/ast: add support for additive built-in fragments

["Antonin Godard" <antonin.godard@bootlin.com>]

Hi,

On Tue Sep 1, 2026 at 9:22 PM CEST, Richard Purdie wrote:
> On Tue, 2026-09-01 at 20:28 +0200, Alexander Kanavin wrote:
>> On Tue, 1 Sept 2026 at 14:15, Richard Purdie via
>> lists.openembedded.org
>> <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
>> 
>> > It is definitely an interesting one and the syntax isn't too bad..
>> > Are
>> > there uses beyond class inherit though?
>> > 
>> > machine/distro were added as they are clear variables in common use
>> > which avoided tons of boilerplate in layer definitions. Do we have
>> > similar needs here or are these inherits better captured in config
>> > fragments?
>> 
>> Antonin first wanted to just add 'real' fragments (that are defined
>> in
>> files) for common class inherits, and it was my idea to implement
>> additive built-ins that make it generic. It's something we can
>> consider and discuss, I don't necessarily insist on a generic
>> implementation.
>> 
>> I guess we can all look at our various local.conf lying around, and
>> check what's piled up in them over the years. In mine, two variables
>> immediately jump out as candidates for additions: IMAGE_INSTALL,
>> IMAGE_FEATURES. Those certainly will not work with regular fragments.
>
> I guess there are a few things to keep in mind.
>
> Firstly, we're never going to replace local.conf, there are always
> going to be some things which users need to do locally for their work
> and these do belong there.
>
> The alternative is a fragment language which is an abbreviated short
> form of the main bitbake syntax and I'm not sure that is feasible or
> desirable.
>
> The things which should become fragments are commonly used groups of
> settings, things which set set as a group.
>
> The machine/distro shortcuts are nice as they cover the biggest control
> everyone sets immediately but beyond that, is there a pressing case?
>
> I guess some of the "classes" are in fact policy "selections" and kind
> of like fragments in their own right but are there enough of them to
> justify specific syntax.

I think the main purpose of such a class fragment would be for classes that
provide build settings, such as the retain or buildstats classes, or rm_work,
etc. Those classes do not mean anything for the target image, they only tweak
what happens during the build. I think it makes sense to set those in
bitbake-setup configuration files.

However, I think classes that affect the build output, such as useradd, should
probably be part of a distro configuration file rather than bitbake-setup files.

With that in mind, I agree that there aren't that many use-cases for a class
fragment, and maybe we should provide everything from our distro configuration
files. But aren't distro conf files supposed to represent policy for the
target image, and only that? Would it be relevant to delegate all build system
settings to bitbake-setup? I guess this patch would somewhat aim to achieve this
separation.

> Once you get above a handful of image features or image install
> packages, that is a packagegroup or a config fragment in their own
> right and I'm worried about the abuse such things might get...
>
> I'm not saying "no" but I do have worries.

I agree that this mechanism could be abused. If this exists, maybe we should
limit this _only_ to adding/removing global classes?

Antonin