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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#232004):
https://lists.openembedded.org/g/openembedded-core/message/232004
Mute This Topic: https://lists.openembedded.org/mt/118010724/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
