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

[Trevor Gamblin <tgamblin@baylibre.com>]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>