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

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

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