Improving DISTRO_FEATURES backfill & opt-out

Improving DISTRO_FEATURES backfill & opt-out

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 4623 bytes --]

Hi all,

We discussed Richard's patch to enable the opengl, ptest, multiarch,
wayland & vulkan DISTRO_FEATURES by default [1] on the patch review call
on Monday. We agreed the idea was sound, but couldn't reach agreement on
the implementation. There were two approaches:

1) Add the new features to `DISTRO_FEATURES_BACKFILL`. This enables them
   automatically for all users, even those who define
   `DISTRO_FEATURES` themselves, which may be surprising. It's possible
   to opt-out of the new features by listing them in
   `DISTRO_FEATURES_BACKFILL_CONSIDERED`.

2) Add the new features to `DISTRO_FEATURES_DEFAULT`. This enables them
   automatically for most users, but does not affect those who define
   `DISTRO_FEATURES` themselves. Opting-out of the new features is less
   straightforward, either you need to fully define `DISTRO_FEATURES`
   yourself without using `DISTRO_FEATURES_DEFAULT`, or you need to use
   `DISTRO_FEATURES:remove` which has its own issues.

I took a step back and looked at how we're handling `DISTRO_FEATURES`
overall. There was some discussion about the terminology
(`DISTRO_FEATURES_BACKFILL_CONSIDERED` was not liked) and some
suggestion that it should be easy to opt-out of any of the default
distro features. So, I'd like to propose a third possible solution:

3) Merge the current contents of `DISTRO_FEATURES_BACKFILL` into
   `DISTRO_FEATURES_DEFAULT`. This variable will be filtered to disable
   any items listed in `DISTRO_FEATURES_OPTOUT` before use, efficiently
   and without the use of `:remove`. Deprecate
   `DISTRO_FEATURES_BACKFILL` and `DISTRO_FEATURES_BACKFILL_CONSIDERED`,
   issuing warnings if either is used.

What does that look like practically? Something like this I think:

    DISTRO_FEATURES_BASELINE = " \
        acl alsa bluetooth debuginfod ext2 ipv4 ipv6 pcmcia usbgadget \
        usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat seccomp \
        pulseaudio gobject-introspection-data ldconfig \
    "

    DISTRO_FEATURES_DEFAULT = "${@filter_default_features('DISTRO_FEATURES', d)}"
    DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"

    DISTRO_FEATURES_OPTOUT ?= "${DISTRO_FEATURES_BACKFILL_CONSIDERED}"

    def filter_default_features(varname, d):
        baseline_features = (d.getVar(varname + "_BASELINE") or "").split()
        optout_features = (d.getVar(varname + "_OPTOUT") or "").split()

        return [feature for feature in baseline_features \
                if feature not in optout_features]

(un-tested, may also need some tweaks for performance)

Applying the filtering as part of the definition of
`DISTRO_FEATURES_DEFAULT` makes it easy to use. If you're already using
`DISTRO_FEATURES_DEFAULT:remove` or `DISTRO_FEATURES:remove`, these will
still work, though we'd encourage you to adopt the new
`DISTRO_FEATURES_OPTOUT` variable. If you're using
`DISTRO_FEATURES_BACKFILL_CONSIDERED`, this would still work but our
encouragement would be louder - we can issue a warning if this is set
saying that it is deprecated and will be removed in a future release.

There is one group adversely impacted by this change - anyone who
defines `DISTRO_FEATURES` fully themselves without including
`DISTRO_FEATURES_DEFAULT` will need to manually add the backfilled
features (pulseaudio, gobject-introspection-data & ldconfig) or adapt
how they set `DISTRO_FEATURES`. Personally I think that having to adapt
to this will not be difficult and it can be well documented as part of
the release notes and migration guide.

A patch to implement the change should be straightforward, it may need a
little effort to address any fall out before release. There are no tests
for the `DISTRO_FEATURES_BACKFILL` logic right now, tests for the
filtering and opt-out variable can be added along with this change.
Impact on the autobuilder should be minimal, I think this is something
we can take in with little risk to the core project so it is unlike the
proposal to change the default init system for poky. The impact is
mostly on users who define their own distro, and we can make migration
as easy as possible as outlined above. I should be able to get this in
before the M3 build if we want to go ahead with this change before the
LTS.

We can extend this to `MACHINE_FEATURES_DEFAULT` as well, deprecating
`MACHINE_FEATURES_BACKFILL` and `MACHINE_FEATURES_BACKFILL_CONSIDERED`.

Thoughts and opinions?

[1]: https://lore.kernel.org/openembedded-core/20260221084230.3219379-2-richard.purdie@linuxfoundation.org/

Best regards,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [OE-core] Improving DISTRO_FEATURES backfill & opt-out

[Jan-Simon Moeller]

Hi all,


[...]
> What does that look like practically? Something like this I think:
> 
>     DISTRO_FEATURES_BASELINE = " \
>         acl alsa bluetooth debuginfod ext2 ipv4 ipv6 pcmcia usbgadget \
>         usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat seccomp \
>         pulseaudio gobject-introspection-data ldconfig \
>     "
> 
>     DISTRO_FEATURES_DEFAULT = "${@filter_default_features('DISTRO_FEATURES',
> d)}" DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
> 
>     DISTRO_FEATURES_OPTOUT ?= "${DISTRO_FEATURES_BACKFILL_CONSIDERED}"
> 
>     def filter_default_features(varname, d):
>         baseline_features = (d.getVar(varname + "_BASELINE") or "").split()
>         optout_features = (d.getVar(varname + "_OPTOUT") or "").split()
> 
>         return [feature for feature in baseline_features \
>                 if feature not in optout_features]
> 

I like the clearer terminology -  +1 .

Best,
Jan-Simon

Re: [Openembedded-architecture] Improving DISTRO_FEATURES backfill & opt-out

[Richard Purdie]

On Thu, 2026-02-26 at 09:59 +0000, Paul Barker via lists.openembedded.org wrote:
> 3) Merge the current contents of `DISTRO_FEATURES_BACKFILL` into
>    `DISTRO_FEATURES_DEFAULT`. This variable will be filtered to disable
>    any items listed in `DISTRO_FEATURES_OPTOUT` before use, efficiently
>    and without the use of `:remove`. Deprecate
>    `DISTRO_FEATURES_BACKFILL` and `DISTRO_FEATURES_BACKFILL_CONSIDERED`,
>    issuing warnings if either is used.
> 
> What does that look like practically? Something like this I think:
> 
>     DISTRO_FEATURES_BASELINE = " \
>         acl alsa bluetooth debuginfod ext2 ipv4 ipv6 pcmcia usbgadget \
>         usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat seccomp \
>         pulseaudio gobject-introspection-data ldconfig \
>     "
> 
>     DISTRO_FEATURES_DEFAULT = "${@filter_default_features('DISTRO_FEATURES', d)}"
>     DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
> 
>     DISTRO_FEATURES_OPTOUT ?= "${DISTRO_FEATURES_BACKFILL_CONSIDERED}"
> 
>     def filter_default_features(varname, d):
>         baseline_features = (d.getVar(varname + "_BASELINE") or "").split()
>         optout_features = (d.getVar(varname + "_OPTOUT") or "").split()
> 
>         return [feature for feature in baseline_features \
>                 if feature not in optout_features]
> 
> (un-tested, may also need some tweaks for performance)
> 
> Applying the filtering as part of the definition of
> `DISTRO_FEATURES_DEFAULT` makes it easy to use. If you're already using
> `DISTRO_FEATURES_DEFAULT:remove` or `DISTRO_FEATURES:remove`, these will
> still work, though we'd encourage you to adopt the new
> `DISTRO_FEATURES_OPTOUT` variable. If you're using
> `DISTRO_FEATURES_BACKFILL_CONSIDERED`, this would still work but our
> encouragement would be louder - we can issue a warning if this is set
> saying that it is deprecated and will be removed in a future release.
> 
> There is one group adversely impacted by this change - anyone who
> defines `DISTRO_FEATURES` fully themselves without including
> `DISTRO_FEATURES_DEFAULT` will need to manually add the backfilled
> features (pulseaudio, gobject-introspection-data & ldconfig) or adapt
> how they set `DISTRO_FEATURES`. Personally I think that having to adapt
> to this will not be difficult and it can be well documented as part of
> the release notes and migration guide.
> 
> A patch to implement the change should be straightforward, it may need a
> little effort to address any fall out before release. There are no tests
> for the `DISTRO_FEATURES_BACKFILL` logic right now, tests for the
> filtering and opt-out variable can be added along with this change.
> Impact on the autobuilder should be minimal, I think this is something
> we can take in with little risk to the core project so it is unlike the
> proposal to change the default init system for poky. The impact is
> mostly on users who define their own distro, and we can make migration
> as easy as possible as outlined above. I should be able to get this in
> before the M3 build if we want to go ahead with this change before the
> LTS.
> 
> We can extend this to `MACHINE_FEATURES_DEFAULT` as well, deprecating
> `MACHINE_FEATURES_BACKFILL` and `MACHINE_FEATURES_BACKFILL_CONSIDERED`.
> 
> Thoughts and opinions?

Keeping DISTRO_FEATURES_DEFAULT around but changing it's meaning does
make me worry about the transition a lot. I also worry a bit about
"default" meaning different things to different people.

After we previously discussed it, I'd had a slightly different take on
what we might do. I was thinking that we might:

Rename:
  DISTRO_FEATURES_BACKFILL -> DISTRO_FEATURES_OPTOUT
  DISTRO_FEATURES_BACKFILL_CONSIDERED -> DISTRO_FEATURES_OPTOUT_CONSIDERED

and then move the contents of DISTRO_FEATURES_DEFAULT into
DISTRO_FEATURES_OPTOUT.

This would make features in "optout" the default, unless you set them
as 'considered'.

You could perhaps have a DISTRO_FEATURES_OPTEDOUT?

Is is probably a question of finding the right naming for them. We need
a core way to say "these are the defaults" and then a "remove these
from the defaults as we explicitly don't want them".

So having said all that, perhaps we can cheat and use:

DISTRO_FEATURES_DEFAULTS and DISTRO_FEATURES_OPTOUT

which would remove the namespace clash issue?

Cheers,

Richard

Re: [Openembedded-architecture] Improving DISTRO_FEATURES backfill & opt-out

[Trevor Gamblin]

On 2026-02-26 07:03, Richard Purdie via lists.openembedded.org wrote:
> On Thu, 2026-02-26 at 09:59 +0000, Paul Barker via lists.openembedded.org wrote:
>> 3) Merge the current contents of `DISTRO_FEATURES_BACKFILL` into
>>     `DISTRO_FEATURES_DEFAULT`. This variable will be filtered to disable
>>     any items listed in `DISTRO_FEATURES_OPTOUT` before use, efficiently
>>     and without the use of `:remove`. Deprecate
>>     `DISTRO_FEATURES_BACKFILL` and `DISTRO_FEATURES_BACKFILL_CONSIDERED`,
>>     issuing warnings if either is used.
>>
>> What does that look like practically? Something like this I think:
>>
>>      DISTRO_FEATURES_BASELINE = " \
>>          acl alsa bluetooth debuginfod ext2 ipv4 ipv6 pcmcia usbgadget \
>>          usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat seccomp \
>>          pulseaudio gobject-introspection-data ldconfig \
>>      "
>>
>>      DISTRO_FEATURES_DEFAULT = "${@filter_default_features('DISTRO_FEATURES', d)}"
>>      DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
>>
>>      DISTRO_FEATURES_OPTOUT ?= "${DISTRO_FEATURES_BACKFILL_CONSIDERED}"
>>
>>      def filter_default_features(varname, d):
>>          baseline_features = (d.getVar(varname + "_BASELINE") or "").split()
>>          optout_features = (d.getVar(varname + "_OPTOUT") or "").split()
>>
>>          return [feature for feature in baseline_features \
>>                  if feature not in optout_features]
>>
>> (un-tested, may also need some tweaks for performance)
>>
>> Applying the filtering as part of the definition of
>> `DISTRO_FEATURES_DEFAULT` makes it easy to use. If you're already using
>> `DISTRO_FEATURES_DEFAULT:remove` or `DISTRO_FEATURES:remove`, these will
>> still work, though we'd encourage you to adopt the new
>> `DISTRO_FEATURES_OPTOUT` variable. If you're using
>> `DISTRO_FEATURES_BACKFILL_CONSIDERED`, this would still work but our
>> encouragement would be louder - we can issue a warning if this is set
>> saying that it is deprecated and will be removed in a future release.
>>
>> There is one group adversely impacted by this change - anyone who
>> defines `DISTRO_FEATURES` fully themselves without including
>> `DISTRO_FEATURES_DEFAULT` will need to manually add the backfilled
>> features (pulseaudio, gobject-introspection-data & ldconfig) or adapt
>> how they set `DISTRO_FEATURES`. Personally I think that having to adapt
>> to this will not be difficult and it can be well documented as part of
>> the release notes and migration guide.
>>
>> A patch to implement the change should be straightforward, it may need a
>> little effort to address any fall out before release. There are no tests
>> for the `DISTRO_FEATURES_BACKFILL` logic right now, tests for the
>> filtering and opt-out variable can be added along with this change.
>> Impact on the autobuilder should be minimal, I think this is something
>> we can take in with little risk to the core project so it is unlike the
>> proposal to change the default init system for poky. The impact is
>> mostly on users who define their own distro, and we can make migration
>> as easy as possible as outlined above. I should be able to get this in
>> before the M3 build if we want to go ahead with this change before the
>> LTS.
>>
>> We can extend this to `MACHINE_FEATURES_DEFAULT` as well, deprecating
>> `MACHINE_FEATURES_BACKFILL` and `MACHINE_FEATURES_BACKFILL_CONSIDERED`.
>>
>> Thoughts and opinions?
> Keeping DISTRO_FEATURES_DEFAULT around but changing it's meaning does
> make me worry about the transition a lot. I also worry a bit about
> "default" meaning different things to different people.
>
> After we previously discussed it, I'd had a slightly different take on
> what we might do. I was thinking that we might:
>
> Rename:
>    DISTRO_FEATURES_BACKFILL -> DISTRO_FEATURES_OPTOUT
>    DISTRO_FEATURES_BACKFILL_CONSIDERED -> DISTRO_FEATURES_OPTOUT_CONSIDERED
>
> and then move the contents of DISTRO_FEATURES_DEFAULT into
> DISTRO_FEATURES_OPTOUT.
>
> This would make features in "optout" the default, unless you set them
> as 'considered'.
>
> You could perhaps have a DISTRO_FEATURES_OPTEDOUT?
>
> Is is probably a question of finding the right naming for them. We need
> a core way to say "these are the defaults" and then a "remove these
> from the defaults as we explicitly don't want them".

As far as naming goes, when I read "DISTRO_FEATURES_OPTOUT" my mind 
assumes whatever is in that list will be filtered from the default. I 
think that's what Paul is suggesting, so I'm in favour of that approach.
I also looked through the variables glossary quickly for EXCLUDE and 
found: 
https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_EXCLUDE
Could "DISTRO_FEATURES_EXCLUDE" be a viable name that stays somewhat 
inline with what we're doing there?

Trevor
>
> So having said all that, perhaps we can cheat and use:
>
> DISTRO_FEATURES_DEFAULTS and DISTRO_FEATURES_OPTOUT
>
> which would remove the namespace clash issue?
>
> Cheers,
>
> Richard
>
>
>
>
>
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#2283): https://lists.openembedded.org/g/openembedded-architecture/message/2283
> Mute This Topic: https://lists.openembedded.org/mt/118009864/7611679
> Group Owner: openembedded-architecture+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [tgamblin@baylibre.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [Openembedded-architecture] Improving DISTRO_FEATURES backfill & opt-out

[Ankur Tyagi]

On Fri, Feb 27, 2026 at 3:07 AM Trevor Gamblin via
lists.openembedded.org <tgamblin=baylibre.com@lists.openembedded.org>
wrote:
>
>
> On 2026-02-26 07:03, Richard Purdie via lists.openembedded.org wrote:
> > On Thu, 2026-02-26 at 09:59 +0000, Paul Barker via lists.openembedded.org wrote:
> >> 3) Merge the current contents of `DISTRO_FEATURES_BACKFILL` into
> >>     `DISTRO_FEATURES_DEFAULT`. This variable will be filtered to disable
> >>     any items listed in `DISTRO_FEATURES_OPTOUT` before use, efficiently
> >>     and without the use of `:remove`. Deprecate
> >>     `DISTRO_FEATURES_BACKFILL` and `DISTRO_FEATURES_BACKFILL_CONSIDERED`,
> >>     issuing warnings if either is used.
> >>
> >> What does that look like practically? Something like this I think:
> >>
> >>      DISTRO_FEATURES_BASELINE = " \
> >>          acl alsa bluetooth debuginfod ext2 ipv4 ipv6 pcmcia usbgadget \
> >>          usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat seccomp \
> >>          pulseaudio gobject-introspection-data ldconfig \
> >>      "
> >>
> >>      DISTRO_FEATURES_DEFAULT = "${@filter_default_features('DISTRO_FEATURES', d)}"
> >>      DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
> >>
> >>      DISTRO_FEATURES_OPTOUT ?= "${DISTRO_FEATURES_BACKFILL_CONSIDERED}"
> >>
> >>      def filter_default_features(varname, d):
> >>          baseline_features = (d.getVar(varname + "_BASELINE") or "").split()
> >>          optout_features = (d.getVar(varname + "_OPTOUT") or "").split()
> >>
> >>          return [feature for feature in baseline_features \
> >>                  if feature not in optout_features]
> >>
> >> (un-tested, may also need some tweaks for performance)
> >>
> >> Applying the filtering as part of the definition of
> >> `DISTRO_FEATURES_DEFAULT` makes it easy to use. If you're already using
> >> `DISTRO_FEATURES_DEFAULT:remove` or `DISTRO_FEATURES:remove`, these will
> >> still work, though we'd encourage you to adopt the new
> >> `DISTRO_FEATURES_OPTOUT` variable. If you're using
> >> `DISTRO_FEATURES_BACKFILL_CONSIDERED`, this would still work but our
> >> encouragement would be louder - we can issue a warning if this is set
> >> saying that it is deprecated and will be removed in a future release.
> >>
> >> There is one group adversely impacted by this change - anyone who
> >> defines `DISTRO_FEATURES` fully themselves without including
> >> `DISTRO_FEATURES_DEFAULT` will need to manually add the backfilled
> >> features (pulseaudio, gobject-introspection-data & ldconfig) or adapt
> >> how they set `DISTRO_FEATURES`. Personally I think that having to adapt
> >> to this will not be difficult and it can be well documented as part of
> >> the release notes and migration guide.
> >>
> >> A patch to implement the change should be straightforward, it may need a
> >> little effort to address any fall out before release. There are no tests
> >> for the `DISTRO_FEATURES_BACKFILL` logic right now, tests for the
> >> filtering and opt-out variable can be added along with this change.
> >> Impact on the autobuilder should be minimal, I think this is something
> >> we can take in with little risk to the core project so it is unlike the
> >> proposal to change the default init system for poky. The impact is
> >> mostly on users who define their own distro, and we can make migration
> >> as easy as possible as outlined above. I should be able to get this in
> >> before the M3 build if we want to go ahead with this change before the
> >> LTS.
> >>
> >> We can extend this to `MACHINE_FEATURES_DEFAULT` as well, deprecating
> >> `MACHINE_FEATURES_BACKFILL` and `MACHINE_FEATURES_BACKFILL_CONSIDERED`.
> >>
> >> Thoughts and opinions?
> > Keeping DISTRO_FEATURES_DEFAULT around but changing it's meaning does
> > make me worry about the transition a lot. I also worry a bit about
> > "default" meaning different things to different people.
> >
> > After we previously discussed it, I'd had a slightly different take on
> > what we might do. I was thinking that we might:
> >
> > Rename:
> >    DISTRO_FEATURES_BACKFILL -> DISTRO_FEATURES_OPTOUT
> >    DISTRO_FEATURES_BACKFILL_CONSIDERED -> DISTRO_FEATURES_OPTOUT_CONSIDERED
> >
> > and then move the contents of DISTRO_FEATURES_DEFAULT into
> > DISTRO_FEATURES_OPTOUT.
> >
> > This would make features in "optout" the default, unless you set them
> > as 'considered'.
> >
> > You could perhaps have a DISTRO_FEATURES_OPTEDOUT?
> >

IMO, OPTOUT vs OPTEDOUT is going to cause further confusion.

> > Is is probably a question of finding the right naming for them. We need
> > a core way to say "these are the defaults" and then a "remove these
> > from the defaults as we explicitly don't want them".
>
> As far as naming goes, when I read "DISTRO_FEATURES_OPTOUT" my mind
> assumes whatever is in that list will be filtered from the default. I
> think that's what Paul is suggesting, so I'm in favour of that approach.
> I also looked through the variables glossary quickly for EXCLUDE and
> found:
> https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-PACKAGE_EXCLUDE
> Could "DISTRO_FEATURES_EXCLUDE" be a viable name that stays somewhat
> inline with what we're doing there?
>

I am also more in favor of explicit variable naming like
DISTRO_FEATURES_INCLUDE and DISTRO_FEATURE_EXCLUDE.
It should also encourage less (or no) use of `:remove`.

cheers
Ankur

> Trevor
> >
> > So having said all that, perhaps we can cheat and use:
> >
> > DISTRO_FEATURES_DEFAULTS and DISTRO_FEATURES_OPTOUT
> >
> > which would remove the namespace clash issue?
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#232028): https://lists.openembedded.org/g/openembedded-core/message/232028
> Mute This Topic: https://lists.openembedded.org/mt/118010724/3619737
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ankur.tyagi85@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>