mbox series

[0/4] Support opt-out of any default machine and distro features

Message ID 20260328-default-features-v1-0-90790864d734@pbarker.dev
Headers show
Series Support opt-out of any default machine and distro features | expand

Message

Paul Barker March 28, 2026, 9:48 a.m. UTC
These changes should be applied *after* the corresponding changes are
applied in meta-yocto [1].

[1]: https://lore.kernel.org/poky/20260328-default-features-v1-0-549331ccfab0@pbarker.dev/T/

These changes implement the third proposal from my email on "Improving
DISTRO_FEATURES backfill & opt-out" [2]:

   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.

[2]: https://lists.openembedded.org/g/openembedded-architecture/topic/improving_distro_features/118009864

DISTRO_FEATURES_DEFAULT is now set from DISTRO_FEATURES_DEFAULT_RAW,
excluding entries listed in DISTRO_FEATURES_OPTED_OUT. _OPTED_OUT was
chosen over _OPTOUT for improved clarity.

This series doesn't include issuing warnings if DISTRO_FEATURES_BACKFILL
or DISTRO_FEATURES_BACKFILL_CONSIDERED is set, that can be added as a
follow up if these changes are accepted.

The change is also carried through to MACHINE_FEATURES to keep things
consistent.

---
Paul Barker (4):
      oelib: utils: Support filtering default features
      meta: Support opting out of any distro features
      meta: Support opting out of any machine features
      lib: oe: Drop backfill support

 meta/classes-global/base.bbclass                   |  7 +--
 meta/classes-recipe/crosssdk.bbclass               |  7 ++-
 meta/classes-recipe/native.bbclass                 |  7 ++-
 meta/classes-recipe/nativesdk.bbclass              |  8 ++--
 meta/conf/bitbake.conf                             |  7 ++-
 meta/conf/distro/include/default-distrovars.inc    | 15 +++---
 meta/conf/distro/include/tclibc-musl.inc           |  2 +-
 meta/conf/distro/include/tclibc-newlib.inc         |  2 +-
 meta/conf/distro/include/tclibc-picolibc.inc       |  2 +-
 meta/conf/documentation.conf                       | 14 +++---
 .../machine/include/loongarch/qemuloongarch.inc    |  3 +-
 meta/conf/machine/include/mips/arch-mips.inc       |  2 +-
 meta/conf/machine/include/powerpc/tune-power5.inc  |  2 +-
 meta/conf/machine/include/powerpc/tune-power6.inc  |  2 +-
 meta/conf/machine/include/powerpc/tune-power7.inc  |  2 +-
 .../conf/machine/include/powerpc/tune-ppce5500.inc |  2 +-
 .../conf/machine/include/powerpc/tune-ppce6500.inc |  2 +-
 meta/conf/machine/include/qemu.inc                 |  4 +-
 meta/conf/machine/include/riscv/qemuriscv.inc      |  2 +-
 meta/conf/machine/include/x86/arch-x86.inc         |  2 +-
 meta/conf/machine/include/x86/x86-base.inc         |  5 +-
 meta/conf/machine/qemux86-64.conf                  |  2 +-
 meta/conf/machine/qemux86.conf                     |  2 +-
 meta/lib/oe/utils.py                               | 54 ++++++++++++++--------
 meta/lib/oeqa/selftest/cases/oelib/utils.py        | 31 ++++++++++++-
 25 files changed, 118 insertions(+), 70 deletions(-)
---
base-commit: b50d6debf7baa555fbfb3521c4f952675bba2d37
change-id: 20260328-default-features-d7f43efcfb63

Best regards,
--  
Paul Barker

Comments

Richard Purdie March 29, 2026, 8:41 a.m. UTC | #1
On Sat, 2026-03-28 at 09:48 +0000, Paul Barker via lists.openembedded.org wrote:
> These changes should be applied *after* the corresponding changes are
> applied in meta-yocto [1].
> 
> [1]:
> https://lore.kernel.org/poky/20260328-default-features-v1-0-549331ccfab0@pbarker.dev/T/
> 
> These changes implement the third proposal from my email on "Improving
> DISTRO_FEATURES backfill & opt-out" [2]:
> 
>    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.
> 
> [2]:
> https://lists.openembedded.org/g/openembedded-architecture/topic/improving_distro_features/118009864
> 
> DISTRO_FEATURES_DEFAULT is now set from DISTRO_FEATURES_DEFAULT_RAW,
> excluding entries listed in DISTRO_FEATURES_OPTED_OUT. _OPTED_OUT was
> chosen over _OPTOUT for improved clarity.
> 
> This series doesn't include issuing warnings if
> DISTRO_FEATURES_BACKFILL
> or DISTRO_FEATURES_BACKFILL_CONSIDERED is set, that can be added as a
> follow up if these changes are accepted.
> 
> The change is also carried through to MACHINE_FEATURES to keep things
> consistent.

Thanks for putting this together. I really don't like "DEAULT_RAW" as a
variable name, we're trying to get away from unclear concepts and I
think adding 'raw' into the mix may cause more confusion that it helps
solve :/. I'd probably have gone with OPTEDOUT or OPTOUT instead but I
know others would argue that differently too.

I did notice some changes like:

-DISTRO_FEATURES_BACKFILL_CONSIDERED += "ldconfig"
+DISTRO_FEATURES_OPTED_OUT:append = "ldconfig"

and was a bit worried we were having to force append operator use? Was
that necessary for ordering reasons or did += work? I spent a lot of
time trying to make sure the previous code worked with += as it was
catching people out and I'm a bit worried this regresses.

Perhaps most problematically, I noticed this preserves the _DEFAULT
variable and behaviour. This wasn't really what I was expecting. I can
understand why you've done it but I'm worried it builds up more legacy
and makes the code harder to understand. Personally, I'm becoming more
in favour of just making the change and letting people adapt, the
complexity is becoming to great in my view. At some point we do need to
switch to something clean and I think this is one of those cases even
if the initial switch is more painful. I suspect this piece may be the
cause of the ordering issues too.

Cheers,

Richard