Requesting information on some variables

Requesting information on some variables

[Rifenbark, Scott M]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

There is a bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3292) stating that we need better documentation describing how DISTRO_FEATURES, COMMON_FEATURES, and MACHINE_FEATURES actually affect the build.  I don't know anything about these variables beyond what is in the reference manual:

http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-DISTRO_FEATURES
http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-MACHINE_FEATURES
(no current entry for  COMMON_FEATURES)

Can anyone provide additional information for these three variables and how they interact with the build system and with one another?

Thanks,
Scott


Bug 3292

The documentation for the following variables:

DISTRO_FEATURES
COMMON_FEATURES
MACHINE_FEATURES

is inadequate to instruct would-be users of how changes will impact the system.

These variables combine to determine various aspects of how images and packages are built. They impact RDEPENDS of various packagegroups, impact the way live images are built, and certainly others. MACHINE_FEATURES as a documented list of values, DISTRO_FEATURES does not. I do not see COMMON_FEATURES listed at all.

A discussion of how these interrelate and how someone can discover the exact impact from the sources would be useful. For example, using "git grep 'contains.*MACHINE_FEATURES.*<FEATURE>'" to discover how the build is impacted would be a useful addition.

It isn't practical to define the dependency chains in the documentation, but providing the user with the background and tools to discover them seems appropriate.


Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)


[-- Attachment #2: Type: text/html, Size: 8705 bytes --]

Re: Requesting information on some variables

[Paul Eggleton]

On Wednesday 17 October 2012 15:32:40 Rifenbark, Scott M wrote:
> There is a bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3292)
> stating that we need better documentation describing how DISTRO_FEATURES,
> COMMON_FEATURES, and MACHINE_FEATURES actually affect the build.  I don't
> know anything about these variables beyond what is in the reference manual:
> 
> http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#va
> r-DISTRO_FEATURES
> http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#v
> ar-MACHINE_FEATURES (no current entry for  COMMON_FEATURES)
> 
> Can anyone provide additional information for these three variables and how
> they interact with the build system and with one another?

Looking at the bug report I'm guessing Darren was looking at the current 
version of the documentation prior to adding a link to the section that lists 
DISTRO_FEATURES options (which only got added recently). However that list is 
incomplete and even then it does not explain how you would determine what the 
actual effect of adding or removing a feature would be.

I think Darren's suggestion of using "git grep" to find the actual effect is 
good, after some preamble that mentions we use the "base_contains" function in 
various recipes and configuration files in order to change behaviour based on 
the presence or absence of features, giving at least one example from the 
current metadata.

Some explanation of how these variables relate to eachother:

* DISTRO_FEATURES is used to enable/disable software features (some of which 
are related to hardware feature support). This is set in the distro .conf file.

* MACHINE_FEATURES describes what hardware features a specific machine 
supports. It is set in the machine .conf file.

* COMBINED_FEATURES lists features both enabled by DISTRO_FEATURES and 
supported by the hardware as declared by MACHINE_FEATURES. It is set 
automatically by the build system.

The COMBINED_FEATURES mechanism allows a BSP to declare that a piece of 
hardware supports a feature, but a person building a distro (or OS) to decide 
that they don't want to support the feature; thus the feature only gets 
enabled in the software if it appears on in both places.

Cheers,
Paul

 
> Thanks,
> Scott
> 
> 
> Bug 3292
> 
> The documentation for the following variables:
> 
> DISTRO_FEATURES
> COMMON_FEATURES
> MACHINE_FEATURES
> 
> is inadequate to instruct would-be users of how changes will impact the
> system.
> 
> These variables combine to determine various aspects of how images and
> packages are built. They impact RDEPENDS of various packagegroups, impact
> the way live images are built, and certainly others. MACHINE_FEATURES as a
> documented list of values, DISTRO_FEATURES does not. I do not see
> COMMON_FEATURES listed at all.
> 
> A discussion of how these interrelate and how someone can discover the exact
> impact from the sources would be useful. For example, using "git grep
> 'contains.*MACHINE_FEATURES.*<FEATURE>'" to discover how the build is
> impacted would be a useful addition.
> 
> It isn't practical to define the dependency chains in the documentation, but
> providing the user with the background and tools to discover them seems
> appropriate.
> 
> 
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702
> 503.341.0418 (cell)
-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Requesting information on some variables

[Rifenbark, Scott M]

This is helpful... thanks Paul.

-----Original Message-----
From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com] 
Sent: Wednesday, October 17, 2012 8:59 AM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Requesting information on some variables

On Wednesday 17 October 2012 15:32:40 Rifenbark, Scott M wrote:
> There is a bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3292)
> stating that we need better documentation describing how DISTRO_FEATURES,
> COMMON_FEATURES, and MACHINE_FEATURES actually affect the build.  I don't
> know anything about these variables beyond what is in the reference manual:
> 
> http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#va
> r-DISTRO_FEATURES
> http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#v
> ar-MACHINE_FEATURES (no current entry for  COMMON_FEATURES)
> 
> Can anyone provide additional information for these three variables and how
> they interact with the build system and with one another?

Looking at the bug report I'm guessing Darren was looking at the current 
version of the documentation prior to adding a link to the section that lists 
DISTRO_FEATURES options (which only got added recently). However that list is 
incomplete and even then it does not explain how you would determine what the 
actual effect of adding or removing a feature would be.

I think Darren's suggestion of using "git grep" to find the actual effect is 
good, after some preamble that mentions we use the "base_contains" function in 
various recipes and configuration files in order to change behaviour based on 
the presence or absence of features, giving at least one example from the 
current metadata.

Some explanation of how these variables relate to eachother:

* DISTRO_FEATURES is used to enable/disable software features (some of which 
are related to hardware feature support). This is set in the distro .conf file.

* MACHINE_FEATURES describes what hardware features a specific machine 
supports. It is set in the machine .conf file.

* COMBINED_FEATURES lists features both enabled by DISTRO_FEATURES and 
supported by the hardware as declared by MACHINE_FEATURES. It is set 
automatically by the build system.

The COMBINED_FEATURES mechanism allows a BSP to declare that a piece of 
hardware supports a feature, but a person building a distro (or OS) to decide 
that they don't want to support the feature; thus the feature only gets 
enabled in the software if it appears on in both places.

Cheers,
Paul

 
> Thanks,
> Scott
> 
> 
> Bug 3292
> 
> The documentation for the following variables:
> 
> DISTRO_FEATURES
> COMMON_FEATURES
> MACHINE_FEATURES
> 
> is inadequate to instruct would-be users of how changes will impact the
> system.
> 
> These variables combine to determine various aspects of how images and
> packages are built. They impact RDEPENDS of various packagegroups, impact
> the way live images are built, and certainly others. MACHINE_FEATURES as a
> documented list of values, DISTRO_FEATURES does not. I do not see
> COMMON_FEATURES listed at all.
> 
> A discussion of how these interrelate and how someone can discover the exact
> impact from the sources would be useful. For example, using "git grep
> 'contains.*MACHINE_FEATURES.*<FEATURE>'" to discover how the build is
> impacted would be a useful addition.
> 
> It isn't practical to define the dependency chains in the documentation, but
> providing the user with the background and tools to discover them seems
> appropriate.
> 
> 
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702
> 503.341.0418 (cell)
-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Requesting information on some variables

[Rudolf Streif]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

Scott,

Thanks for addressing this confusing part. The list of DISTRO_FEATURES (DF)
and MACHINE_FEATURES (MF) in the documentation also does not seem to be
complete. For instance, vfat is (at least the code in bitbake.conf that
intersects DF and MF suggests so) is a MF as well as a DF.

It also seems that any package is fair game for DF (which makes sense) but
the documentation says "The items below are valid options for
DISTRO_FEATURES<http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-DISTRO_FEATURES>
:".

Some elaboration on the features would be great too. From the explanation
it is not obvious why ext2 is considered a DF as well as a MF. The same
seems to be the case with vfat (although not listed in the documentation).
Other file systems e.g. ext3 etc. are purely considered DF.

Here are the variables from a build environment building for the Beagleboard

bitbake core-image-minimal -e | grep MACHINE_FEATURES
MACHINE_FEATURES="apm usbgadget usbhost vfat alsa"

bitbake core-image-minimal -e | grep DISTRO_FEATURES
DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia usbgadget
usbhost wifi xattr nfs zeroconf pci 3g x11 ipv4 ipv6 libc-backtrace
libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets
libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg
libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm
libc-libm-big libc-locales libc-locale-code libc-memusage libc-nis
libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc
libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp
libc-posix-regexp-glibc libc-posix-wchar-io largefile opengl pulseaudio"

bitbake core-image-minimal -e | grep COMBINED_FEATURES
COMBINED_FEATURES="alsa usbgadget usbhost"

CF seems to be an intersection of DF and MF.  If I remove usbgadget from MF
then CF will of course not contain it. DF will still have it. What actually
does get included with the image? Is it DF - [list of all available machine
features] + CF?

[list of all available machine features] is then the superset of MF that is
typically defined in a machine.conf file. That list must be implicit
somewhere in the classes/configuration files somewhere, possibly
bitbake.conf.

That leads me to the next question. I have seen BSPs that include 'screen'
into MF in their machine.conf files. That feature is also in the
documentation. But it does not show up anywhere in DF or bitbake.conf etc.

Cheers,
Rudi

[-- Attachment #2: Type: text/html, Size: 3583 bytes --]

Re: Requesting information on some variables

[Rifenbark, Scott M]

[-- Attachment #1: Type: text/plain, Size: 5402 bytes --]

Rudi,

Thanks for the added investigation here.  The original bug report listed COMMON_FEATURES as an undocumented variable.  I see, however, that the variable referred to by both you and Paul Eggleton is COMBINED_FEATURES.  I just did a grep through my entire poky tree, which had built out the core-image-minimal image for the qemux86 MACHINE and came up empty for "COMMON_FEATURES" except where the string is part of other variables.  So, it appears there is no COMMON_FEATURES variable.

According to Paul, COMBINED_FEATURES is a list of features common to both MACHINE_FEATURES and DISTRO_FEATURES.

It also seems that the lists presented in the documentation for both valid distro and machine options are not really finite lists.  I am trying to get an answer to that.  But, the fact that you grep'ed out such a huge list of DF below shows that they far exceed the 16 features listed in the documentation.  I'll update the preamble to the "Distro" and "Machine" sections in the reference manual when I get the real story on those lists.

I don't know the relationship between "features" and "packages"...  maybe it is a one-to-one relationship.  But, there are some other variables that affect packages and features (according to the documentation) that are considered during the build.  These are the ones listed in the manual's glossary section:


*         MACHINE_ESSENTIAL_EXTRA_RDEPENDS

*         MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS

*         MACHINE_EXTRA_RDEPENDS

*         MACHINE_EXTRA-RRECOMMENDS

*         DISTRO_EXTRA_RRECOMMENDS

*         DISTRO_FEATURES_BACKFILL

*         DISTRO_FEATURES_BACKFILL_CONSIDERED

*         MACHINE_FEATURES_BACKFILL

*         MACHINE_FEATURES_BACKFILL_CONSIDERED

I suspect that there is a DISTRO_EXTRA_RDEPENDS variable as well but I don't have it in the manual (should be added if so).  Also, not sure if there are variables for DISTRO_ESSENTIAL_EXTRA_RDEPENDS and DISTRO_ESSENTIAL_EXTRA_RRECOMMENDS.  If those really exist, then I need to add them as well.

Finally, the BACKFILL variables also contribute to the MACHINE_FEATURES and DISTRO_FEATURES set.  It looks like *_FEATURES_BACKFILL, which is set in the bitbake.conf file, is a way to make sure a feature is always included as part of *_FEATURES. While *_BACKFILL_CONSIDERED is used in specific machine configurations (<machine>.conf) to disable a particular feature when it also appears with *_FEATURES_BACKFILL.   So these variables add to the mix also.

I have emails out asking questions and am trying to fully understand it myself.

Thanks,
Scott


From: rstreif@linuxfoundation.org [mailto:rstreif@linuxfoundation.org] On Behalf Of Rudolf Streif
Sent: Wednesday, October 17, 2012 1:16 PM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Requesting information on some variables

Scott,

Thanks for addressing this confusing part. The list of DISTRO_FEATURES (DF) and MACHINE_FEATURES (MF) in the documentation also does not seem to be complete. For instance, vfat is (at least the code in bitbake.conf that intersects DF and MF suggests so) is a MF as well as a DF.

It also seems that any package is fair game for DF (which makes sense) but the documentation says "The items below are valid options for DISTRO_FEATURES<http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-DISTRO_FEATURES>:".

Some elaboration on the features would be great too. From the explanation it is not obvious why ext2 is considered a DF as well as a MF. The same seems to be the case with vfat (although not listed in the documentation). Other file systems e.g. ext3 etc. are purely considered DF.

Here are the variables from a build environment building for the Beagleboard

bitbake core-image-minimal -e | grep MACHINE_FEATURES
MACHINE_FEATURES="apm usbgadget usbhost vfat alsa"

bitbake core-image-minimal -e | grep DISTRO_FEATURES
DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g x11 ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm libc-libm-big libc-locales libc-locale-code libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc libc-posix-wchar-io largefile opengl pulseaudio"

bitbake core-image-minimal -e | grep COMBINED_FEATURES
COMBINED_FEATURES="alsa usbgadget usbhost"

CF seems to be an intersection of DF and MF.  If I remove usbgadget from MF then CF will of course not contain it. DF will still have it. What actually does get included with the image? Is it DF - [list of all available machine features] + CF?

[list of all available machine features] is then the superset of MF that is typically defined in a machine.conf file. That list must be implicit somewhere in the classes/configuration files somewhere, possibly bitbake.conf.

That leads me to the next question. I have seen BSPs that include 'screen' into MF in their machine.conf files. That feature is also in the documentation. But it does not show up anywhere in DF or bitbake.conf etc.

Cheers,
Rudi

[-- Attachment #2: Type: text/html, Size: 17353 bytes --]

Re: Requesting information on some variables

[Paul Eggleton]

On Wednesday 17 October 2012 21:07:20 Rifenbark, Scott M wrote:
> Thanks for the added investigation here.  The original bug report listed
> COMMON_FEATURES as an undocumented variable.  I see, however, that the
> variable referred to by both you and Paul Eggleton is COMBINED_FEATURES.  I
> just did a grep through my entire poky tree, which had built out the
> core-image-minimal image for the qemux86 MACHINE and came up empty for
> "COMMON_FEATURES" except where the string is part of other variables.  So,
> it appears there is no COMMON_FEATURES variable.
>
> According to Paul, COMBINED_FEATURES is a list of features common to both
> MACHINE_FEATURES and DISTRO_FEATURES.

Yes, the variable is COMBINED_FEATURES.

> It also seems that the lists presented in the documentation for both valid
> distro and machine options are not really finite lists.

Correct, the list is not set in stone. People are free to add new features to 
MACHINE_FEATURES and DISTRO_FEATURES in their own setups and check for them in 
their own recipes/configuration files if it helps them handle different machines 
they want to target or different types of distros they want to build 
respectively. However, we should document all of the features we have defined 
out of the box.

> But, the fact that you grep'ed out such a huge list of
> DF below shows that they far exceed the 16 features listed in the
> documentation.  I'll update the preamble to the "Distro" and "Machine"
> sections in the reference manual when I get the real story on those lists.

I can try to help document all of the features. It's possible that some of 
them that we refer to are effectively placeholders that don't do anything at 
the moment (e.g. ipv6 in DISTRO_FEATURES).

> I don't know the relationship between "features" and "packages"...  maybe it
> is a one-to-one relationship. 

It's definitely not 1-1, and sometimes a feature doesn't just control the 
installation of a package or packages, but influences how certain recipes are 
built, e.g. it might determine whether a particular configure option is 
specified within do_configure for a particular recipe.

> But, there are some other variables that
> affect packages and features (according to the documentation) that are
> considered during the build.  These are the ones listed in the manual's
> glossary section:
> 
> *         MACHINE_ESSENTIAL_EXTRA_RDEPENDS
> 
> *         MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS
> 
> *         MACHINE_EXTRA_RDEPENDS
> 
> *         MACHINE_EXTRA-RRECOMMENDS
> 
> *         DISTRO_EXTRA_RRECOMMENDS

Let's not muddy the waters too much here - these aren't directly related to 
features although they are related to machine and distro configuration.

> I suspect that there is a DISTRO_EXTRA_RDEPENDS variable as well but I don't
> have it in the manual (should be added if so).  

Yes, that exists and should be documented.

> Also, not sure if there are variables for DISTRO_ESSENTIAL_EXTRA_RDEPENDS
> and DISTRO_ESSENTIAL_EXTRA_RRECOMMENDS.  If those really exist, then I need
> to add them as well.

No, there are no such variables.

> Finally, the BACKFILL variables also contribute to the MACHINE_FEATURES and
> DISTRO_FEATURES set.  It looks like *_FEATURES_BACKFILL, which is set in
> the bitbake.conf file, is a way to make sure a feature is always included
> as part of *_FEATURES. While *_BACKFILL_CONSIDERED is used in specific
> machine configurations (<machine>.conf) to disable a particular feature
> when it also appears with *_FEATURES_BACKFILL.   So these variables add to
> the mix also.

We have added the 9.4 section on "Feature backfilling" that should cover what 
these are for and how they work. If the explanation there is not clear enough 
then by all means lets enhance that section and/or the entries in the glossary 
for these variables, but they are at least documented now.
 
Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Requesting information on some variables

[Burton, Ross]

On 18 October 2012 10:20, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>> I don't know the relationship between "features" and "packages"...  maybe it
>> is a one-to-one relationship.
>
> It's definitely not 1-1, and sometimes a feature doesn't just control the
> installation of a package or packages, but influences how certain recipes are
> built, e.g. it might determine whether a particular configure option is
> specified within do_configure for a particular recipe.

A concrete example might help.  For example there is a "bluetooth"
machine feature that means bluez (the bluetooth daemon) is built and
added to the image, ConnMan enabled bluetooth support, and so on.

Ross

Re: Requesting information on some variables

[Burton, Ross]

On 18 October 2012 10:33, Burton, Ross <ross.burton@intel.com> wrote:
> A concrete example might help.  For example there is a "bluetooth"
> machine feature that means bluez (the bluetooth daemon) is built and
> added to the image, ConnMan enabled bluetooth support, and so on.

I say machine feature, I mean distro feature.

Ross

Re: Requesting information on some variables

[Rifenbark, Scott M]

I have cleaned some of this stuff up.  Still need to add DISTRO_EXTRA_RDEPENDS.

See the ref manual at http://yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html

Scott

-----Original Message-----
From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com] 
Sent: Thursday, October 18, 2012 2:20 AM
To: Rifenbark, Scott M
Cc: Rudolf Streif; yocto@yoctoproject.org
Subject: Re: [yocto] Requesting information on some variables

On Wednesday 17 October 2012 21:07:20 Rifenbark, Scott M wrote:
> Thanks for the added investigation here.  The original bug report listed
> COMMON_FEATURES as an undocumented variable.  I see, however, that the
> variable referred to by both you and Paul Eggleton is COMBINED_FEATURES.  I
> just did a grep through my entire poky tree, which had built out the
> core-image-minimal image for the qemux86 MACHINE and came up empty for
> "COMMON_FEATURES" except where the string is part of other variables.  So,
> it appears there is no COMMON_FEATURES variable.
>
> According to Paul, COMBINED_FEATURES is a list of features common to both
> MACHINE_FEATURES and DISTRO_FEATURES.

Yes, the variable is COMBINED_FEATURES.

> It also seems that the lists presented in the documentation for both valid
> distro and machine options are not really finite lists.

Correct, the list is not set in stone. People are free to add new features to 
MACHINE_FEATURES and DISTRO_FEATURES in their own setups and check for them in 
their own recipes/configuration files if it helps them handle different machines 
they want to target or different types of distros they want to build 
respectively. However, we should document all of the features we have defined 
out of the box.

> But, the fact that you grep'ed out such a huge list of
> DF below shows that they far exceed the 16 features listed in the
> documentation.  I'll update the preamble to the "Distro" and "Machine"
> sections in the reference manual when I get the real story on those lists.

I can try to help document all of the features. It's possible that some of 
them that we refer to are effectively placeholders that don't do anything at 
the moment (e.g. ipv6 in DISTRO_FEATURES).

> I don't know the relationship between "features" and "packages"...  maybe it
> is a one-to-one relationship. 

It's definitely not 1-1, and sometimes a feature doesn't just control the 
installation of a package or packages, but influences how certain recipes are 
built, e.g. it might determine whether a particular configure option is 
specified within do_configure for a particular recipe.

> But, there are some other variables that
> affect packages and features (according to the documentation) that are
> considered during the build.  These are the ones listed in the manual's
> glossary section:
> 
> *         MACHINE_ESSENTIAL_EXTRA_RDEPENDS
> 
> *         MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS
> 
> *         MACHINE_EXTRA_RDEPENDS
> 
> *         MACHINE_EXTRA-RRECOMMENDS
> 
> *         DISTRO_EXTRA_RRECOMMENDS

Let's not muddy the waters too much here - these aren't directly related to 
features although they are related to machine and distro configuration.

> I suspect that there is a DISTRO_EXTRA_RDEPENDS variable as well but I don't
> have it in the manual (should be added if so).  

Yes, that exists and should be documented.

> Also, not sure if there are variables for DISTRO_ESSENTIAL_EXTRA_RDEPENDS
> and DISTRO_ESSENTIAL_EXTRA_RRECOMMENDS.  If those really exist, then I need
> to add them as well.

No, there are no such variables.

> Finally, the BACKFILL variables also contribute to the MACHINE_FEATURES and
> DISTRO_FEATURES set.  It looks like *_FEATURES_BACKFILL, which is set in
> the bitbake.conf file, is a way to make sure a feature is always included
> as part of *_FEATURES. While *_BACKFILL_CONSIDERED is used in specific
> machine configurations (<machine>.conf) to disable a particular feature
> when it also appears with *_FEATURES_BACKFILL.   So these variables add to
> the mix also.

We have added the 9.4 section on "Feature backfilling" that should cover what 
these are for and how they work. If the explanation there is not clear enough 
then by all means lets enhance that section and/or the entries in the glossary 
for these variables, but they are at least documented now.
 
Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre