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 (#232028):
https://lists.openembedded.org/g/openembedded-core/message/232028
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]]
-=-=-=-=-=-=-=-=-=-=-=-
