Hi all, We discussed Richard's patch to enable the opengl, ptest, multiarch, wayland & vulkan DISTRO_FEATURES by default [1] on the patch review call on Monday. We agreed the idea was sound, but couldn't reach agreement on the implementation. There were two approaches:
1) Add the new features to `DISTRO_FEATURES_BACKFILL`. This enables them
automatically for all users, even those who define
`DISTRO_FEATURES` themselves, which may be surprising. It's possible
to opt-out of the new features by listing them in
`DISTRO_FEATURES_BACKFILL_CONSIDERED`.
2) Add the new features to `DISTRO_FEATURES_DEFAULT`. This enables them
automatically for most users, but does not affect those who define
`DISTRO_FEATURES` themselves. Opting-out of the new features is less
straightforward, either you need to fully define `DISTRO_FEATURES`
yourself without using `DISTRO_FEATURES_DEFAULT`, or you need to use
`DISTRO_FEATURES:remove` which has its own issues.
I took a step back and looked at how we're handling `DISTRO_FEATURES`
overall. There was some discussion about the terminology
(`DISTRO_FEATURES_BACKFILL_CONSIDERED` was not liked) and some
suggestion that it should be easy to opt-out of any of the default
distro features. So, I'd like to propose a third possible solution:
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?
[1]:
https://lore.kernel.org/openembedded-core/[email protected]/
Best regards,
--
Paul Barker
signature.asc
Description: This is a digitally signed message part
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#231996): https://lists.openembedded.org/g/openembedded-core/message/231996 Mute This Topic: https://lists.openembedded.org/mt/118009865/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
