On Fri, Feb 27, 2026 at 3:07 AM Trevor Gamblin via lists.openembedded.org <[email protected]> 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 (#232062): https://lists.openembedded.org/g/openembedded-core/message/232062 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]] -=-=-=-=-=-=-=-=-=-=-=-
