diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 9b1ead6..d9065b3 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -214,13 +214,13 @@
 =====================
 
 The ``blacklist`` class prevents the OpenEmbedded build system from
-building specific recipes (blacklists them). To use this class, inherit
+building specific recipes. To use this class, inherit
 the class globally and set :term:`PNBLACKLIST` for
-each recipe you wish to blacklist. Specify the :term:`PN`
+each recipe you wish to ignore. Specify the :term:`PN`
 value as a variable flag (varflag) and provide a reason, which is
 reported, if the package is requested to be built as the value. For
-example, if you want to blacklist a recipe called "exoticware", you add
-the following to your ``local.conf`` or distribution configuration::
+example, if you want to ignore a recipe called "exoticware", you
+add the following to your ``local.conf`` or distribution configuration::
 
    INHERIT += "blacklist"
    PNBLACKLIST[exoticware] = "Not supported by our organization."
@@ -515,6 +515,14 @@
 -  Extensions that use ``distutils``-based build systems require the
    ``distutils`` class in their recipes.
 
+   .. note::
+
+      ``distutils`` has been deprecated in Python 3.10 and will be removed
+      in Python 3.12. For this reason the ``distutils3*`` classes are now
+      deprecated and will be removed from core in the near future. Instead,
+      use the ``setuptools3*`` classes.
+
+
 -  Extensions that use build systems based on ``setuptools3`` require
    the :ref:`setuptools3 <ref-classes-setuptools3>` class in their
    recipes.
@@ -570,11 +578,11 @@
 .. note::
 
    The user and group operations added using the
-   extrausers
+   :ref:`extrausers <ref-classes-extrausers>`
    class are not tied to a specific recipe outside of the recipe for the
    image. Thus, the operations can be performed across the image as a
    whole. Use the
-   useradd
+   :ref:`useradd <ref-classes-useradd>`
    class to add user and group configuration to a specific recipe.
 
 Here is an example that uses this class in an image recipe::
@@ -845,10 +853,10 @@
    icecc.
 
 If you do not want the Icecream distributed compile support to apply to
-specific recipes or classes, you can effectively "blacklist" them by
-listing the recipes and classes using the
+specific recipes or classes, you can ask them to be ignored by Icecream
+by listing the recipes and classes using the
 :term:`ICECC_USER_PACKAGE_BL` and
-:term:`ICECC_USER_CLASS_BL`, variables,
+:term:`ICECC_USER_CLASS_BL` variables,
 respectively, in your ``local.conf`` file. Doing so causes the
 OpenEmbedded build system to handle these compilations locally.
 
@@ -1362,9 +1370,9 @@
 
 Only a single Initramfs bundle can be added to the FIT image created by
 ``kernel-fitimage`` and the Initramfs bundle in FIT is optional.
-In case of Initramfs, the kernel is configured to be bundled with the rootfs
+In case of Initramfs, the kernel is configured to be bundled with the root filesystem
 in the same binary (example: zImage-initramfs-:term:`MACHINE`.bin).
-When the kernel is copied to RAM and executed, it unpacks the Initramfs rootfs.
+When the kernel is copied to RAM and executed, it unpacks the Initramfs root filesystem.
 The Initramfs bundle can be enabled when :term:`INITRAMFS_IMAGE`
 is specified and that :term:`INITRAMFS_IMAGE_BUNDLE` is set to 1.
 The address where the Initramfs bundle is to be loaded by U-boot is specified
@@ -1712,13 +1720,13 @@
 ``overlayfs.bbclass``
 =======================
 
-It's often desired in Embedded System design to have a read-only rootfs.
+It's often desired in Embedded System design to have a read-only root filesystem.
 But a lot of different applications might want to have read-write access to
 some parts of a filesystem. It can be especially useful when your update mechanism
-overwrites the whole rootfs, but you may want your application data to be preserved
+overwrites the whole root filesystem, but you may want your application data to be preserved
 between updates. The :ref:`overlayfs <ref-classes-overlayfs>` class provides a way
 to achieve that by means of ``overlayfs`` and at the same time keeping the base
-rootfs read-only.
+root filesystem read-only.
 
 To use this class, set a mount point for a partition ``overlayfs`` is going to use as upper
 layer in your machine configuration. The underlying file system can be anything that
@@ -1742,7 +1750,8 @@
 
 To support several mount points you can use a different variable flag. Assuming we
 want to have a writable location on the file system, but do not need that the data
-survives a reboot, then we could have a ``mnt-overlay.mount`` unit for a ``tmpfs`` file system.
+survives a reboot, then we could have a ``mnt-overlay.mount`` unit for a ``tmpfs``
+file system.
 
 In your machine configuration::
 
@@ -1752,9 +1761,68 @@
 
   OVERLAYFS_WRITABLE_PATHS[mnt-overlay] = "/usr/share/another-application"
 
+On a practical note, your application recipe might require multiple
+overlays to be mounted before running to avoid writing to the underlying
+file system (which can be forbidden in case of read-only file system)
+To achieve that :ref:`overlayfs <ref-classes-overlayfs>` provides a ``systemd``
+helper service for mounting overlays. This helper service is named
+``${PN}-overlays.service`` and can be depended on in your application recipe
+(named ``application`` in the following example) ``systemd`` unit by adding
+to the unit the following::
+
+  [Unit]
+  After=application-overlays.service
+  Requires=application-overlays.service
+
 .. note::
 
    The class does not support the ``/etc`` directory itself, because ``systemd`` depends on it.
+   In order to get ``/etc`` in overlayfs, see :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`.
+
+.. _ref-classes-overlayfs-etc:
+
+``overlayfs-etc.bbclass``
+=========================
+
+In order to have the ``/etc`` directory in overlayfs a special handling at early
+boot stage is required. The idea is to supply a custom init script that mounts
+``/etc`` before launching the actual init program, because the latter already
+requires ``/etc`` to be mounted.
+
+Example usage in image recipe::
+
+   IMAGE_FEATURES += "overlayfs-etc"
+
+.. note::
+
+   This class must not be inherited directly. Use :term:`IMAGE_FEATURES` or :term:`EXTRA_IMAGE_FEATURES`
+
+Your machine configuration should define at least the device, mount point, and file system type
+you are going to use for ``overlayfs``::
+
+  OVERLAYFS_ETC_MOUNT_POINT = "/data"
+  OVERLAYFS_ETC_DEVICE = "/dev/mmcblk0p2"
+  OVERLAYFS_ETC_FSTYPE ?= "ext4"
+
+To control more mount options you should consider setting mount options
+(``defaults`` is used by default)::
+
+  OVERLAYFS_ETC_MOUNT_OPTIONS = "wsync"
+
+The class provides two options for ``/sbin/init`` generation:
+
+- The default option is to rename the original ``/sbin/init`` to ``/sbin/init.orig``
+  and place the generated init under original name, i.e. ``/sbin/init``. It has an advantage
+  that you won't need to change any kernel parameters in order to make it work,
+  but it poses a restriction that package-management can't be used, because updating
+  the init manager would remove the generated script.
+
+- If you wish to keep original init as is, you can set::
+
+   OVERLAYFS_ETC_USE_ORIG_INIT_NAME = "0"
+
+  Then the generated init will be named ``/sbin/preinit`` and you would need to extend your
+  kernel parameters manually in your bootloader configuration.
 
 .. _ref-classes-own-mirrors:
 
@@ -2316,6 +2384,17 @@
 use build systems based on ``setuptools``. If your recipe uses these
 build systems, the recipe needs to inherit the ``setuptools3`` class.
 
+.. _ref-classes-setuptools3-base:
+
+``setuptools3-base.bbclass``
+============================
+
+The ``setuptools3-base`` class provides a reusable base for other classes
+that support building Python version 3.x extensions. If you need
+functionality that is not provided by the :ref:`setuptools3 <ref-classes-setuptools3>` class, you may
+want to ``inherit setuptools3-base``. Some recipes do not need the tasks
+in the :ref:`setuptools3 <ref-classes-setuptools3>` class and inherit this class instead.
+
 .. _ref-classes-sign_rpm:
 
 ``sign_rpm.bbclass``
@@ -2796,11 +2875,10 @@
 usage by the package on the target. For example, if you have packages
 that contain system services that should be run under their own user or
 group, you can use these classes to enable creation of the user or
-group. The ``meta-skeleton/recipes-skeleton/useradd/useradd-example.bb``
+group. The :oe_git:`meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
+</openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb>`
 recipe in the :term:`Source Directory` provides a simple
 example that shows how to add three users and groups to two packages.
-See the ``useradd-example.bb`` recipe for more information on how to use
-these classes.
 
 The ``useradd_base`` class provides basic functionality for user or
 groups settings.
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index 6f2970d..e06dfd9 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -302,10 +302,10 @@
 ``local.conf`` configuration file::
 
    PREMIRRORS:prepend = "\
-       git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-       ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-       http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-       https://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n"
+       git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+       ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+       http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+       https://.*/.* &YOCTO_DL_URL;/mirror/sources/"
 
 These changes cause the build system to intercept Git, FTP, HTTP, and
 HTTPS requests and direct them to the ``http://`` sources mirror. You
@@ -342,10 +342,10 @@
 file as long as the :term:`PREMIRRORS` server is current::
 
    PREMIRRORS:prepend = "\
-       git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-       ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-       http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-       https://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n"
+       git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+       ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+       http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+       https://.*/.* &YOCTO_DL_URL;/mirror/sources/"
    BB_FETCH_PREMIRRORONLY = "1"
 
 These changes would cause the build system to successfully fetch source
diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst
index ded6532..f7abb41 100644
--- a/poky/documentation/ref-manual/features.rst
+++ b/poky/documentation/ref-manual/features.rst
@@ -219,6 +219,10 @@
 -  *empty-root-password:* Sets the root password to an empty string,
    which allows logins with a blank password.
 
+-  *overlayfs-etc:* Configures the ``/etc`` directory to be in ``overlayfs``.
+   This allows to store device specific information elsewhere, especially
+   if the root filesystem is configured to be read-only.
+
 -  *package-management:* Installs package management tools and preserves
    the package manager database.
 
diff --git a/poky/documentation/ref-manual/images.rst b/poky/documentation/ref-manual/images.rst
index c6a7239..0e3351b 100644
--- a/poky/documentation/ref-manual/images.rst
+++ b/poky/documentation/ref-manual/images.rst
@@ -112,7 +112,7 @@
    development headers and libraries to form a complete standalone SDK
    and is suitable for development using the target.
 
--  ``core-image-testmaster``: A "master" image designed to be used for
+-  ``core-image-testmaster``: A "controller" image designed to be used for
    automated runtime testing. Provides a "known good" image that is
    deployed to a separate partition so that you can boot into it and use
    it to deploy a second image to be tested. You can find more
diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst
index cac9f2f..885c721 100644
--- a/poky/documentation/ref-manual/kickstart.rst
+++ b/poky/documentation/ref-manual/kickstart.rst
@@ -54,8 +54,9 @@
 .. note::
 
    The mount program must understand the PARTUUID syntax you use with
-   ``--use-uuid`` and non-root *mountpoint*, including swap. The BusyBox
-   versions of these application are currently excluded.
+   ``--use-uuid`` and non-root *mountpoint*, including swap. The default
+   configuration of BusyBox in OpenEmbedded supports this, but this may
+   be disabled in custom configurations.
 
 Here is an example that uses "/" as the mountpoint. The command uses
 ``--ondisk`` to force the partition onto the ``sdb`` disk::
@@ -86,7 +87,7 @@
 
    If you use ``--source rootfs``, Wic creates a partition as large as
    needed and fills it with the contents of the root filesystem pointed
-   to by the ``-r`` command-line option or the equivalent rootfs derived
+   to by the ``-r`` command-line option or the equivalent root filesystem derived
    from the ``-e`` command-line option. The filesystem type used to
    create the partition is driven by the value of the ``--fstype``
    option specified for the partition. See the entry on ``--fstype``
@@ -95,7 +96,7 @@
    If you use ``--source plugin-name``, Wic creates a partition as large
    as needed and fills it with the contents of the partition that is
    generated by the specified plugin name using the data pointed to by
-   the ``-r`` command-line option or the equivalent rootfs derived from
+   the ``-r`` command-line option or the equivalent root filesystem derived from
    the ``-e`` command-line option. Exactly what those contents are and
    filesystem type used are dependent on the given plugin
    implementation.
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index 792c099..3364311 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -28,7 +28,7 @@
 .. note::
 
    -  At the end of each message, the name of the associated QA test (as
-      listed in the ":ref:`insane.bbclass <ref-classes-insane>`"
+      listed in the ":ref:`ref-classes-insane`"
       section) appears within square brackets.
 
    -  As mentioned, this list of error and warning messages is for QA
@@ -749,7 +749,7 @@
 variables, respectively. You can also disable checks within a particular
 recipe using :term:`INSANE_SKIP`. For information on
 how to work with the QA checks, see the
-":ref:`insane.bbclass <ref-classes-insane>`" section.
+":ref:`ref-classes-insane`" section.
 
 .. note::
 
diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index 5f00edb..5d2e3a8 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -231,7 +231,7 @@
 -----------------------
 
 The OpenEmbedded build system creates this directory when you enable
-build history via the ``buildhistory`` class file. The directory
+build history via the :ref:`buildhistory <ref-classes-buildhistory>` class file. The directory
 organizes build information into image, packages, and SDK
 subdirectories. For information on the build history feature, see the
 ":ref:`dev-manual/common-tasks:maintaining build output quality`"
diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
index d12e8df..d7b7cec 100644
--- a/poky/documentation/ref-manual/system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -37,17 +37,13 @@
 Currently, the Yocto Project is supported on the following
 distributions:
 
--  Ubuntu 16.04 (LTS)
-
 -  Ubuntu 18.04 (LTS)
 
 -  Ubuntu 20.04 (LTS)
 
--  Fedora 30
+-  Fedora 33
 
--  Fedora 31
-
--  Fedora 32
+-  Fedora 34
 
 -  CentOS 7.x
 
@@ -59,8 +55,11 @@
 
 -  Debian GNU/Linux 10.x (Buster)
 
--  openSUSE Leap 15.1
+-  Debian GNU/Linux 11.x (Bullseye)
 
+-  OpenSUSE Leap 15.1
+
+-  OpenSUSE Leap 15.2
 
 .. note::
 
diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst
index 299969d..b51462b 100644
--- a/poky/documentation/ref-manual/tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -80,7 +80,7 @@
 Recipes implementing this task should inherit the
 :ref:`deploy <ref-classes-deploy>` class and should write the output
 to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be
-confused with ``${DEPLOY_DIR}``. The ``deploy`` class sets up
+confused with ``${DEPLOY_DIR}``. The :ref:`deploy <ref-classes-deploy>` class sets up
 ``do_deploy`` as a shared state (sstate) task that can be accelerated
 through sstate use. The sstate mechanism takes care of copying the
 output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
@@ -102,7 +102,7 @@
 .. note::
 
    You do not need to add ``before do_build`` to the ``addtask`` command
-   (though it is harmless), because the ``base`` class contains the following::
+   (though it is harmless), because the :ref:`base <ref-classes-base>` class contains the following::
 
            do_build[recrdeptask] += "do_deploy"
 
@@ -326,21 +326,19 @@
        file://file;apply=yes \
        "
 
-Conversely, if you have a directory full of patch files and you want to
-exclude some so that the ``do_patch`` task does not apply them during
-the patch phase, you can use the "apply=no" parameter with the
+Conversely, if you have a file whose file type is ``.patch`` or ``.diff``
+and you want to exclude it so that the ``do_patch`` task does not apply
+it during the patch phase, you can use the "apply=no" parameter with the
 :term:`SRC_URI` statement::
 
    SRC_URI = " \
        git://path_to_repo/some_package \
-       file://path_to_lots_of_patch_files \
-       file://path_to_lots_of_patch_files/patch_file5;apply=no \
+       file://file1.patch \
+       file://file2.patch;apply=no \
        "
 
-In the
-previous example, assuming all the files in the directory holding the
-patch files end with either ``.patch`` or ``.diff``, every file would be
-applied as a patch by default except for the ``patch_file5`` patch.
+In the previous example ``file1.patch`` would be applied as a patch by default
+while ``file2.patch`` would not be applied.
 
 You can find out more about the patching process in the
 ":ref:`overview-manual/concepts:patching`" section in
@@ -417,7 +415,7 @@
 
 Removes work files after the OpenEmbedded build system has finished with
 them. You can learn more by looking at the
-":ref:`rm_work.bbclass <ref-classes-rm-work>`" section.
+":ref:`ref-classes-rm-work`" section.
 
 .. _ref-tasks-unpack:
 
diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst
index eccae91..09e0a98 100644
--- a/poky/documentation/ref-manual/terms.rst
+++ b/poky/documentation/ref-manual/terms.rst
@@ -134,10 +134,27 @@
       the Texas Instruments ARM Cortex-A8 development board).
 
    :term:`Container Layer`
-      Layers that hold other layers. An example of a container layer is
-      OpenEmbedded's `meta-openembedded
-      <https://github.com/openembedded/meta-openembedded>`_ layer. The
-      ``meta-openembedded`` layer contains many ``meta-*`` layers.
+      A flexible definition that typically refers to a single Git checkout
+      which contains multiple (and typically related) sub-layers which can
+      be included independently in your project's ``bblayers.conf`` file.
+
+      In some cases, such as with OpenEmbedded's
+      `meta-openembedded <https://github.com/openembedded/meta-openembedded>`_
+      layer, the top level ``meta-openembedded/`` directory is not itself an actual layer,
+      so you would never explicitly include it in a ``bblayers.conf`` file;
+      rather, you would include any number of its layer subdirectories, such as
+      `meta-openembedded/meta-oe <https://github.com/openembedded/meta-openembedded/tree/master/meta-oe>`_,
+      `meta-openembedded/meta-python <https://github.com/openembedded/meta-openembedded/tree/master/meta-python>`_
+      and so on.
+
+      On the other hand, some container layers (such as
+      `meta-security <https://git.yoctoproject.org/cgit/cgit.cgi/meta-security>`_)
+      have a top-level directory that is itself an actual layer, as well as
+      a variety of sub-layers, both of which could be included in your
+      ``bblayers.conf`` file.
+
+      In either case, the phrase "container layer" is simply used to describe
+      a directory structure which contains multiple valid OpenEmbedded layers.
 
    :term:`Cross-Development Toolchain`
       In general, a cross-development toolchain is a collection of software
@@ -387,7 +404,7 @@
 
    :term:`Upstream`
       A reference to source code or repositories that are not
-      local to the development system but located in a master area that is
+      local to the development system but located in a remote area that is
       controlled by the maintainer of the source code. For example, in
       order for a developer to work on a particular piece of code, they
       need to first get a copy of it from an "upstream" source.
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index b9e9771..b062116 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -56,7 +56,7 @@
          ALTERNATIVE:busybox = "sh sed test bracket"
 
       For more information on the alternatives system, see the
-      ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
+      ":ref:`ref-classes-update-alternatives`"
       section.
 
    :term:`ALTERNATIVE_LINK_NAME`
@@ -76,7 +76,7 @@
          If :term:`ALTERNATIVE_LINK_NAME` is not defined, it defaults to ``${bindir}/name``.
 
       For more information on the alternatives system, see the
-      ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
+      ":ref:`ref-classes-update-alternatives`"
       section.
 
    :term:`ALTERNATIVE_PRIORITY`
@@ -92,7 +92,7 @@
          ALTERNATIVE_PRIORITY_pkg[name] = "priority"
 
       For more information on the alternatives system, see the
-      ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
+      ":ref:`ref-classes-update-alternatives`"
       section.
 
    :term:`ALTERNATIVE_TARGET`
@@ -122,8 +122,7 @@
          task while retaining support for the command if necessary.
 
       For more information on the alternatives system, see the
-      ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
-      section.
+      ":ref:`ref-classes-update-alternatives`" section.
 
    :term:`ANY_OF_DISTRO_FEATURES`
       When inheriting the
@@ -400,7 +399,7 @@
          where:
 
             action is:
-               ABORT:     Immediately abort the build when
+               ABORT:     Immediately stop the build when
                           a threshold is broken.
                STOPTASKS: Stop the build after the currently
                           executing tasks have finished when
@@ -438,7 +437,7 @@
       The first example works only if you also provide the
       :term:`BB_DISKMON_WARNINTERVAL`
       variable in the ``conf/local.conf``. This example causes the build
-      system to immediately abort when either the disk space in
+      system to immediately stop when either the disk space in
       ``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops
       below 100 Kbytes. Because two directories are provided with the
       variable, the build system also issue a warning when the disk space
@@ -452,7 +451,7 @@
       directory drops below 1 Gbyte. No disk monitoring occurs for the free
       inodes in this case.
 
-      The final example immediately aborts the build when the number of
+      The final example immediately stops the build when the number of
       free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No
       disk space monitoring for the directory itself occurs in this case.
 
@@ -641,8 +640,10 @@
       introduce a hard dependency on those other layers.
 
       Use the following form for :term:`BBFILES_DYNAMIC`:
-      collection_name:filename_pattern The following example identifies two
-      collection names and two filename patterns::
+      ``collection_name:filename_pattern``.
+
+      The following example identifies two collection names and two
+      filename patterns::
 
          BBFILES_DYNAMIC += " \
             clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
@@ -650,7 +651,7 @@
             "
 
       This next example shows an error message that occurs because invalid
-      entries are found, which cause parsing to abort:
+      entries are found, which cause parsing to fail:
 
       .. code-block:: none
 
@@ -771,7 +772,7 @@
       :ref:`binconfig-disabled <ref-classes-binconfig-disabled>` class,
       this variable specifies binary configuration scripts to disable in
       favor of using ``pkg-config`` to query the information. The
-      ``binconfig-disabled`` class will modify the specified scripts to
+      :ref:`binconfig-disabled <ref-classes-binconfig-disabled>` class will modify the specified scripts to
       return an error so that calls to them can be easily found and
       replaced.
 
@@ -801,7 +802,7 @@
       ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`.
       You can also find general
       information on the class in the
-      ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
+      ":ref:`ref-classes-binconfig`" section.
 
    :term:`BP`
       The base recipe name and version but without any special recipe name
@@ -939,13 +940,13 @@
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies whether or not to commit the build
       history output in a local Git repository. If set to "1", this local
-      repository will be maintained automatically by the ``buildhistory``
+      repository will be maintained automatically by the :ref:`buildhistory <ref-classes-buildhistory>`
       class and a commit will be created on every build for changes to each
       top-level subdirectory of the build history output (images, packages,
       and sdk). If you want to track changes to build history over time,
       you should set this value to "1".
 
-      By default, the ``buildhistory`` class does not commit the build
+      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class does not commit the build
       history output in a local Git repository::
 
          BUILDHISTORY_COMMIT ?= "0"
@@ -962,7 +963,7 @@
       email@host". Providing an email address or host that is not valid
       does not produce an error.
 
-      By default, the ``buildhistory`` class sets the variable as follows::
+      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class sets the variable as follows::
 
          BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
 
@@ -970,9 +971,9 @@
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies the directory in which build history
       information is kept. For more information on how the variable works,
-      see the ``buildhistory.class``.
+      see the ``buildhistory.bbclass`` file.
 
-      By default, the ``buildhistory`` class sets the directory as follows::
+      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class sets the directory as follows::
 
          BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
 
@@ -999,7 +1000,7 @@
          This saves one file per task and lists the SHA-256 checksums for
          each file staged (i.e. the output of the task).
 
-      By default, the ``buildhistory`` class enables the following
+      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class enables the following
       features::
 
          BUILDHISTORY_FEATURES ?= "image package sdk"
@@ -1015,7 +1016,7 @@
       any file. Specifying an invalid path does not produce an error.
       Consequently, you can include files that might not always be present.
 
-      By default, the ``buildhistory`` class provides paths to the
+      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class provides paths to the
       following files::
 
          BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
@@ -1028,7 +1029,7 @@
       useful when build history is populated from multiple sources that may not
       all use the same top level directory.
 
-      By default, the ``buildhistory`` class sets the variable as follows::
+      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class sets the variable as follows::
 
          BUILDHISTORY_PATH_PREFIX_STRIP ?= ""
 
@@ -1047,7 +1048,7 @@
       that you have set up manually using ``git remote`` within the local
       repository.
 
-      By default, the ``buildhistory`` class sets the variable as follows::
+      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class sets the variable as follows::
 
          BUILDHISTORY_PUSH_REPO ?= ""
 
@@ -1321,7 +1322,7 @@
       The default value, which is "CLOSED Proprietary", for
       :term:`COPYLEFT_LICENSE_EXCLUDE` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
-      is inherited by the ``archiver`` class.
+      is inherited by the :ref:`archiver <ref-classes-archiver>` class.
 
    :term:`COPYLEFT_LICENSE_INCLUDE`
       A space-separated list of licenses to include in the source archived
@@ -1332,7 +1333,7 @@
 
       The default value is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
-      is inherited by the ``archiver`` class. The default value includes
+      is inherited by the :ref:`archiver <ref-classes-archiver>` class. The default value includes
       "GPL*", "LGPL*", and "AGPL*".
 
    :term:`COPYLEFT_PN_EXCLUDE`
@@ -1347,7 +1348,7 @@
       The default value, which is "" indicating to not explicitly exclude
       any recipes by name, for :term:`COPYLEFT_PN_EXCLUDE` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
-      is inherited by the ``archiver`` class.
+      is inherited by the :ref:`archiver <ref-classes-archiver>` class.
 
    :term:`COPYLEFT_PN_INCLUDE`
       A list of recipes to include in the source archived by the
@@ -1361,7 +1362,7 @@
       The default value, which is "" indicating to not explicitly include
       any recipes by name, for :term:`COPYLEFT_PN_INCLUDE` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
-      is inherited by the ``archiver`` class.
+      is inherited by the :ref:`archiver <ref-classes-archiver>` class.
 
    :term:`COPYLEFT_RECIPE_TYPES`
       A space-separated list of recipe types to include in the source
@@ -1371,7 +1372,7 @@
 
       The default value, which is "target*", for :term:`COPYLEFT_RECIPE_TYPES`
       is set by the :ref:`copyleft_filter <ref-classes-copyleft_filter>`
-      class, which is inherited by the ``archiver`` class.
+      class, which is inherited by the :ref:`archiver <ref-classes-archiver>` class.
 
    :term:`COPY_LIC_DIRS`
       If set to "1" along with the
@@ -1803,11 +1804,11 @@
    :term:`DEPLOYDIR`
       When inheriting the :ref:`deploy <ref-classes-deploy>` class, the
       :term:`DEPLOYDIR` points to a temporary work area for deployed files that
-      is set in the ``deploy`` class as follows::
+      is set in the :ref:`deploy <ref-classes-deploy>` class as follows::
 
          DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
 
-      Recipes inheriting the ``deploy`` class should copy files to be
+      Recipes inheriting the :ref:`deploy <ref-classes-deploy>` class should copy files to be
       deployed into :term:`DEPLOYDIR`, and the class will take care of copying
       them into :term:`DEPLOY_DIR_IMAGE`
       afterwards.
@@ -1850,7 +1851,7 @@
 
    :term:`DISTRO_EXTRA_RDEPENDS`
       Specifies a list of distro-specific packages to add to all images.
-      This variable takes affect through ``packagegroup-base`` so the
+      This variable takes effect through ``packagegroup-base`` so the
       variable only really applies to the more full-featured images that
       include ``packagegroup-base``. You can use this variable to keep
       distro policy out of generic images. As with all other distro
@@ -1983,8 +1984,7 @@
 
    :term:`DISTUTILS_SETUP_PATH`
       When used by recipes that inherit the
-      :ref:`distutils3 <ref-classes-distutils3>` or
-      :ref:`setuptools3 <ref-classes-setuptools3>` class, this variable should
+      :ref:`distutils3 <ref-classes-distutils3>` class, this variable should
       be used to specify the directory in which the ``setup.py`` file is
       located if it is not at the root of the source tree (as specified by
       :term:`S`). For example, in a recipe where the sources are fetched from
@@ -1994,6 +1994,13 @@
          S = "${WORKDIR}/git"
          DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule"
 
+      .. note::
+
+         ``distutils`` has been deprecated in Python 3.10 and will be removed
+         in Python 3.12. For this reason, the use of :ref:`distutils3 <ref-classes-distutils3>`
+         is deprecated. Instead use :ref:`setuptools3 <ref-classes-setuptools3>` and the
+         :term:`SETUPTOOLS_SETUP_PATH` variable.
+
    :term:`DL_DIR`
       The central download directory used by the build process to store
       downloads. By default, :term:`DL_DIR` gets files suitable for mirroring
@@ -2077,7 +2084,7 @@
       errors by the OpenEmbedded build system. You set this variable in
       your distribution configuration file. For a list of the checks you
       can control with this variable, see the
-      ":ref:`insane.bbclass <ref-classes-insane>`" section.
+      ":ref:`ref-classes-insane`" section.
 
    :term:`EXCLUDE_FROM_SHLIBS`
       Triggers the OpenEmbedded build system's shared libraries resolver to
@@ -2156,7 +2163,7 @@
       system uses to locate unpacked recipe source code.
 
       For more information on ``externalsrc.bbclass``, see the
-      ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
+      ":ref:`ref-classes-externalsrc`" section. You
       can also find information on how to use this variable in the
       ":ref:`dev-manual/common-tasks:building software from an external source`"
       section in the Yocto Project Development Tasks Manual.
@@ -2170,7 +2177,7 @@
       Directory.
 
       For more information on ``externalsrc.bbclass``, see the
-      ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
+      ":ref:`ref-classes-externalsrc`" section. You
       can also find information on how to use this variable in the
       ":ref:`dev-manual/common-tasks:building software from an external source`"
       section in the Yocto Project Development Tasks Manual.
@@ -2291,7 +2298,7 @@
       group configurations to a specific recipe.
 
       The set list of commands you can configure using the
-      :term:`EXTRA_USERS_PARAMS` is shown in the ``extrausers`` class. These
+      :term:`EXTRA_USERS_PARAMS` is shown in the :ref:`extrausers <ref-classes-extrausers>` class. These
       commands map to the normal Unix commands of the same names::
 
          # EXTRA_USERS_PARAMS = "\
@@ -2626,7 +2633,7 @@
    :term:`FONT_PACKAGES`
       When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
       this variable identifies packages containing font files that need to
-      be cached by Fontconfig. By default, the ``fontcache`` class assumes
+      be cached by Fontconfig. By default, the :ref:`fontcache <ref-classes-fontcache>` class assumes
       that fonts are in the recipe's main package (i.e.
       ``${``\ :term:`PN`\ ``}``). Use this variable if fonts you
       need are in a package other than that main package.
@@ -2665,6 +2672,13 @@
    :term:`GDB`
       The minimal command and arguments to run the GNU Debugger.
 
+   :term:`GIR_EXTRA_LIBS_PATH`
+      Allows to specify an extra search path for ``.so`` files
+      in GLib related recipes using GObject introspection,
+      and which do not compile without this setting.
+      See the ":ref:`dev-manual/common-tasks:enabling gobject introspection support`"
+      section for details.
+
    :term:`GITDIR`
       The directory in which a local copy of a Git repository is stored
       when it is cloned.
@@ -2834,7 +2848,7 @@
    :term:`ICECC_DISABLED`
       Disables or enables the ``icecc`` (Icecream) function. For more
       information on this function and best practices for using this
-      variable, see the ":ref:`icecc.bbclass <ref-classes-icecc>`"
+      variable, see the ":ref:`ref-classes-icecc`"
       section.
 
       Setting this variable to "1" in your ``local.conf`` disables the
@@ -2892,9 +2906,9 @@
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
       your ``local.conf`` file.
 
-      When you list classes using this variable, you are "blacklisting"
-      them from distributed compilation across remote hosts. Any classes
-      you list will be distributed and compiled locally.
+      When you list classes using this variable, the recipes inheriting
+      those classes will not benefit from distributed compilation across
+      remote hosts. Instead they will be built locally.
 
    :term:`ICECC_USER_PACKAGE_BL`
       Identifies user recipes that you do not want the Icecream distributed
@@ -2902,9 +2916,9 @@
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
       your ``local.conf`` file.
 
-      When you list packages using this variable, you are "blacklisting"
-      them from distributed compilation across remote hosts. Any packages
-      you list will be distributed and compiled locally.
+      When you list recipes using this variable, you are excluding them
+      from distributed compilation across remote hosts. Instead they will
+      be built locally.
 
    :term:`ICECC_USER_PACKAGE_WL`
       Identifies user recipes that use an empty
@@ -3731,7 +3745,7 @@
 
          INSANE_SKIP:${PN} += "dev-so"
 
-      See the ":ref:`insane.bbclass <ref-classes-insane>`" section for a
+      See the ":ref:`ref-classes-insane`" section for a
       list of the valid QA checks you can specify using this variable.
 
    :term:`INSTALL_TIMEZONE_FILE`
@@ -3888,7 +3902,7 @@
       typically append this variable to enable extended image types. An
       example is the "kernel-fitimage", which enables fitImage support and
       resides in ``meta/classes/kernel-fitimage.bbclass``. You can register
-      custom kernel image types with the ``kernel`` class using this
+      custom kernel image types with the :ref:`kernel <ref-classes-kernel>` class using this
       variable.
 
    :term:`KERNEL_DEVICETREE`
@@ -4116,7 +4130,7 @@
    :term:`KERNEL_VERSION`
       Specifies the version of the kernel as extracted from ``version.h``
       or ``utsrelease.h`` within the kernel sources. Effects of setting
-      this variable do not take affect until the kernel has been
+      this variable do not take effect until the kernel has been
       configured. Consequently, attempting to refer to this variable in
       contexts prior to configuration will not work.
 
@@ -4283,7 +4297,7 @@
       that the :ref:`debian <ref-classes-debian>` class applies its
       naming policy to given a recipe that packages multiple libraries.
 
-      This variable works in conjunction with the ``debian`` class.
+      This variable works in conjunction with the :ref:`debian <ref-classes-debian>` class.
 
    :term:`LIC_FILES_CHKSUM`
       Checksums of the license text in the recipe source code.
@@ -4364,9 +4378,9 @@
       section in the Yocto Project Development Tasks Manual.
 
    :term:`LICENSE_FLAGS`
-      Specifies additional flags for a recipe you must whitelist through
+      Specifies additional flags for a recipe you must allow through
       :term:`LICENSE_FLAGS_WHITELIST` in
-      order to allow the recipe to be built. When providing multiple flags,
+      order for the recipe to be built. When providing multiple flags,
       separate them with spaces.
 
       This value is independent of :term:`LICENSE` and is
@@ -4379,8 +4393,7 @@
    :term:`LICENSE_FLAGS_WHITELIST`
       Lists license flags that when specified in
       :term:`LICENSE_FLAGS` within a recipe should not
-      prevent that recipe from being built. This practice is otherwise
-      known as "whitelisting" license flags. For more information, see the
+      prevent that recipe from being built.  For more information, see the
       ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
       section in the Yocto Project Development Tasks Manual.
 
@@ -4733,7 +4746,7 @@
       configuration file, a distribution configuration file, an append file
       for the recipe, or the recipe itself). If you use this variable, you
       must also be sure to list the module name in the
-      :term:`KERNEL_MODULE_AUTOLOAD`
+      :term:`KERNEL_MODULE_PROBECONF`
       variable.
 
       Here is the general syntax::
@@ -4908,9 +4921,7 @@
 
       See the ``meta/classes/binconfig.bbclass`` in the
       :term:`Source Directory` for details on how this class
-      applies these additional sed command arguments. For general
-      information on the ``binconfig`` class, see the
-      ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
+      applies these additional sed command arguments.
 
    :term:`OE_IMPORTS`
       An internal variable used to tell the OpenEmbedded build system what
@@ -5084,7 +5095,7 @@
 
       For information on packaging and build performance effects as a
       result of the package manager in use, see the
-      ":ref:`package.bbclass <ref-classes-package>`" section.
+      ":ref:`ref-classes-package`" section.
 
    :term:`PACKAGE_DEBUG_SPLIT_STYLE`
       Determines how to split up and package debug and source information
@@ -5186,8 +5197,8 @@
       .. note::
 
          You can use the :term:`PACKAGE_FEED_ARCHS`
-         variable to whitelist specific package architectures. If you do
-         not need to whitelist specific architectures, which is a common
+         variable to allow specific package architectures. If you do
+         not need to allow specific architectures, which is a common
          case, you can omit this variable. Omitting the variable results in
          all available architectures for the current machine being included
          into remote package feeds.
@@ -5303,7 +5314,7 @@
    :term:`PACKAGE_WRITE_DEPS`
       Specifies a list of dependencies for post-installation and
       pre-installation scripts on native/cross tools. If your
-      post-installation or pre-installation script can execute at rootfs
+      post-installation or pre-installation script can execute at root filesystem
       creation time rather than on the target but depends on a native tool
       in order to execute, you need to list the tools in
       :term:`PACKAGE_WRITE_DEPS`.
@@ -5855,10 +5866,10 @@
       :term:`Build Directory`::
 
          PREMIRRORS:prepend = "\
-             git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-             ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-             http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n \
-             https://.*/.* &YOCTO_DL_URL;/mirror/sources/ \n"
+             git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+             ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+             http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+             https://.*/.* &YOCTO_DL_URL;/mirror/sources/"
 
       These changes cause the
       build system to intercept Git, FTP, HTTP, and HTTPS requests and
@@ -6007,7 +6018,7 @@
       names used when installing the Python headers and libraries in
       sysroot (e.g. ``.../python3.3m/...``).
 
-      Recipes that inherit the ``distutils3`` class during cross-builds also
+      Recipes that inherit the :ref:`distutils3 <ref-classes-distutils3>` class during cross-builds also
       use this variable to locate the headers and libraries of the
       appropriate Python that the extension is targeting.
 
@@ -6198,7 +6209,7 @@
    :term:`RM_WORK_EXCLUDE`
       With ``rm_work`` enabled, this variable specifies a list of recipes
       whose work directories should not be removed. See the
-      ":ref:`rm_work.bbclass <ref-classes-rm-work>`" section for more
+      ":ref:`ref-classes-rm-work`" section for more
       details.
 
    :term:`ROOT_HOME`
@@ -6583,9 +6594,9 @@
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
 
       This list overrides the variables specified using the
-      :term:`SDK_LOCAL_CONF_BLACKLIST`
-      variable as well as any variables identified by automatic
-      blacklisting due to the "/" character being found at the start of the
+      :term:`SDK_LOCAL_CONF_BLACKLIST` variable as well as
+      other variables automatically added due to the "/" character
+      being found at the start of the
       value, which is usually indicative of being a path and thus might not
       be valid on the system where the SDK is installed.
 
@@ -6756,23 +6767,21 @@
          $ bitbake -c populate_sdk imagename
 
    :term:`SDKMACHINE`
-      The machine for which the SDK is built. In other words, the SDK is
-      built such that it runs on the target you specify with the
-      :term:`SDKMACHINE` value. The value points to a corresponding ``.conf``
-      file under ``conf/machine-sdk/``.
+      The machine for which the SDK is built. In other words, the SDK is built
+      such that it runs on the target you specify with the :term:`SDKMACHINE`
+      value. The value points to a corresponding ``.conf`` file under
+      ``conf/machine-sdk/`` in the enabled layers, for example ``aarch64``,
+      ``i586``, ``i686``, ``ppc64``, ``ppc64le``, and ``x86_64`` are
+      :oe_git:`available in OpenEmbedded-Core </openembedded-core/tree/meta/conf/machine-sdk>`.
 
-      You can use "i686" and "x86_64" as possible values for this variable.
-      The variable defaults to "i686" and is set in the local.conf file in
-      the Build Directory.
-      ::
-
-         SDKMACHINE ?= "i686"
+      The variable defaults to :term:`BUILD_ARCH` so that SDKs are built for the
+      architecture of the build machine.
 
       .. note::
 
          You cannot set the :term:`SDKMACHINE`
          variable in your distribution configuration file. If you do, the
-         configuration will not take affect.
+         configuration will not take effect.
 
    :term:`SDKPATH`
       Defines the path offered to the user for installation of the SDK that
@@ -6837,6 +6846,30 @@
 
          EXTRA_IMAGE_FEATURES += "read-only-rootfs"
 
+   :term:`SETUPTOOLS_BUILD_ARGS`
+      When used by recipes that inherit the
+      :ref:`setuptools3 <ref-classes-setuptools3>` class, this variable can
+      be used to specify additional arguments to be passed to ``setup.py build``
+      in the ``setuptools3_do_compile()`` task.
+
+   :term:`SETUPTOOLS_INSTALL_ARGS`
+      When used by recipes that inherit the
+      :ref:`setuptools3 <ref-classes-setuptools3>` class, this variable can
+      be used to specify additional arguments to be passed to ``setup.py install``
+      in the ``setuptools3_do_install()`` task.
+
+   :term:`SETUPTOOLS_SETUP_PATH`
+      When used by recipes that inherit the
+      :ref:`setuptools3 <ref-classes-setuptools3>` class, this variable should
+      be used to specify the directory in which the ``setup.py`` file is
+      located if it is not at the root of the source tree (as specified by
+      :term:`S`). For example, in a recipe where the sources are fetched from
+      a Git repository and ``setup.py`` is in a ``python/pythonmodule``
+      subdirectory, you would have this::
+
+         S = "${WORKDIR}/git"
+         SETUPTOOLS_SETUP_PATH = "${S}/python/pythonmodule"
+
    :term:`SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS`
       A list of recipe dependencies that should not be used to determine
       signatures of tasks from one recipe when they depend on tasks from
@@ -7018,91 +7051,13 @@
       for additional information.
 
    :term:`SRC_URI`
-      The list of source files - local or remote. This variable tells the
-      OpenEmbedded build system which bits to pull in for the build and how
-      to pull them in. For example, if the recipe or append file only needs
-      to fetch a tarball from the Internet, the recipe or append file uses
-      a single :term:`SRC_URI` entry. On the other hand, if the recipe or
-      append file needs to fetch a tarball, apply two patches, and include
-      a custom file, the recipe or append file would include four instances
-      of the variable.
 
-      The following list explains the available URI protocols. URI
-      protocols are highly dependent on particular BitBake Fetcher
-      submodules. Depending on the fetcher BitBake uses, various URL
-      parameters are employed. For specifics on the supported Fetchers, see
-      the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers`" section in the
-      BitBake User Manual.
+      See the BitBake manual for the initial description for this variable:
+      :term:`bitbake:SRC_URI`.
 
-      -  ``file://`` - Fetches files, which are usually files shipped
-         with the :term:`Metadata`, from the local machine (e.g.
-         :ref:`patch <overview-manual/concepts:patching>` files).
-         The path is relative to the :term:`FILESPATH`
-         variable. Thus, the build system searches, in order, from the
-         following directories, which are assumed to be a subdirectories of
-         the directory in which the recipe file (``.bb``) or append file
-         (``.bbappend``) resides:
+      The following features are added by OpenEmbedded and the Yocto Project.
 
-         -  ``${BPN}`` - The base recipe name without any special suffix
-            or version numbers.
-
-         -  ``${BP}`` - ``${BPN}-${PV}``. The base recipe name and
-            version but without any special package name suffix.
-
-         -  *files -* Files within a directory, which is named ``files``
-            and is also alongside the recipe or append file.
-
-         .. note::
-
-            If you want the build system to pick up files specified through
-            a
-            SRC_URI
-            statement from your append file, you need to be sure to extend
-            the
-            FILESPATH
-            variable by also using the
-            FILESEXTRAPATHS
-            variable from within your append file.
-
-      -  ``bzr://`` - Fetches files from a Bazaar revision control
-         repository.
-
-      -  ``git://`` - Fetches files from a Git revision control
-         repository.
-
-      -  ``osc://`` - Fetches files from an OSC (openSUSE Build service)
-         revision control repository.
-
-      -  ``repo://`` - Fetches files from a repo (Git) repository.
-
-      -  ``ccrc://`` - Fetches files from a ClearCase repository.
-
-      -  ``http://`` - Fetches files from the Internet using ``http``.
-
-      -  ``https://`` - Fetches files from the Internet using ``https``.
-
-      -  ``ftp://`` - Fetches files from the Internet using ``ftp``.
-
-      -  ``cvs://`` - Fetches files from a CVS revision control
-         repository.
-
-      -  ``hg://`` - Fetches files from a Mercurial (``hg``) revision
-         control repository.
-
-      -  ``p4://`` - Fetches files from a Perforce (``p4``) revision
-         control repository.
-
-      -  ``ssh://`` - Fetches files from a secure shell.
-
-      -  ``svn://`` - Fetches files from a Subversion (``svn``) revision
-         control repository.
-
-      -  ``npm://`` - Fetches JavaScript modules from a registry.
-
-      -  ``az://`` - Fetches files from an Azure Storage account.
-
-      There are standard and recipe-specific options for :term:`SRC_URI`. Here are
-      standard ones:
+      There are standard and recipe-specific options. Here are standard ones:
 
       -  ``apply`` - Whether to apply the patch or not. The default
          action is to apply the patch.
@@ -7135,41 +7090,12 @@
       -  ``notrev`` - Apply the patch only if :term:`SRCREV` is not equal to
          ``rev``.
 
-      Here are some additional options worth mentioning:
+      .. note::
 
-      -  ``unpack`` - Controls whether or not to unpack the file if it is
-         an archive. The default action is to unpack the file.
-
-      -  ``destsuffix`` - Places the file (or extracts its contents) into
-         the specified subdirectory of :term:`WORKDIR` when
-         the Git fetcher is used.
-
-      -  ``subdir`` - Places the file (or extracts its contents) into the
-         specified subdirectory of :term:`WORKDIR` when the local (``file://``)
-         fetcher is used.
-
-      -  ``localdir`` - Places the file (or extracts its contents) into
-         the specified subdirectory of :term:`WORKDIR` when the CVS fetcher is
-         used.
-
-      -  ``subpath`` - Limits the checkout to a specific subpath of the
-         tree when using the Git fetcher is used.
-
-      -  ``name`` - Specifies a name to be used for association with
-         :term:`SRC_URI` checksums or :term:`SRCREV` when you have more than one
-         file or git repository specified in :term:`SRC_URI`. For example::
-
-            SRC_URI = "git://example.com/foo.git;name=first \
-                       git://example.com/bar.git;name=second \
-                       http://example.com/file.tar.gz;name=third"
-
-            SRCREV_first = "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15"
-            SRCREV_second = "e242ed3bffccdf271b7fbaf34ed72d089537b42f"
-            SRC_URI[third.sha256sum] = "13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de"
-
-
-      -  ``downloadfilename`` - Specifies the filename used when storing
-         the downloaded file.
+         If you want the build system to pick up files specified through
+         a :term:`SRC_URI` statement from your append file, you need to be
+         sure to extend the :term:`FILESPATH` variable by also using the
+         :term:`FILESEXTRAPATHS` variable from within your append file.
 
    :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH`
       By default, the OpenEmbedded build system automatically detects
@@ -8119,7 +8045,7 @@
       on enabling, running, and writing these tests, see the
       ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual and the
-      ":ref:`testimage*.bbclass <ref-classes-testimage*>`" section.
+      ":ref:`ref-classes-testimage*`" section.
 
    :term:`THISDIR`
       The directory in which the file BitBake is currently parsing is
@@ -8213,11 +8139,6 @@
       information on setting up a cross-development environment, see the
       :doc:`/sdk-manual/index` manual.
 
-   :term:`TOPDIR`
-      The top-level :term:`Build Directory`. BitBake
-      automatically sets this variable when you initialize your build
-      environment using :ref:`structure-core-script`.
-
    :term:`TRANSLATED_TARGET_ARCH`
       A sanitized version of :term:`TARGET_ARCH`. This
       variable is used where the architecture is needed in a value where
@@ -8334,40 +8255,6 @@
 
          TUNE_PKGARCH:tune-core2-32 = "core2-32"
 
-   :term:`TUNEABI`
-      An underlying Application Binary Interface (ABI) used by a particular
-      tuning in a given toolchain layer. Providers that use prebuilt
-      libraries can use the :term:`TUNEABI`,
-      :term:`TUNEABI_OVERRIDE`, and
-      :term:`TUNEABI_WHITELIST` variables to check
-      compatibility of tunings against their selection of libraries.
-
-      If :term:`TUNEABI` is undefined, then every tuning is allowed. See the
-      :ref:`sanity <ref-classes-sanity>` class to see how the variable is
-      used.
-
-   :term:`TUNEABI_OVERRIDE`
-      If set, the OpenEmbedded system ignores the
-      :term:`TUNEABI_WHITELIST` variable.
-      Providers that use prebuilt libraries can use the
-      :term:`TUNEABI_OVERRIDE`, :term:`TUNEABI_WHITELIST`, and
-      :term:`TUNEABI` variables to check compatibility of a
-      tuning against their selection of libraries.
-
-      See the :ref:`sanity <ref-classes-sanity>` class to see how the
-      variable is used.
-
-   :term:`TUNEABI_WHITELIST`
-      A whitelist of permissible :term:`TUNEABI` values. If
-      :term:`TUNEABI_WHITELIST` is not set, all tunes are allowed. Providers
-      that use prebuilt libraries can use the :term:`TUNEABI_WHITELIST`,
-      :term:`TUNEABI_OVERRIDE`, and :term:`TUNEABI`
-      variables to check compatibility of a tuning against their selection
-      of libraries.
-
-      See the :ref:`sanity <ref-classes-sanity>` class to see how the
-      variable is used.
-
    :term:`TUNECONFLICTS[feature]`
       Specifies CPU or Application Binary Interface (ABI) tuning features
       that conflict with feature.
@@ -8783,7 +8670,7 @@
       warnings by the OpenEmbedded build system. You set this variable in
       your distribution configuration file. For a list of the checks you
       can control with this variable, see the
-      ":ref:`insane.bbclass <ref-classes-insane>`" section.
+      ":ref:`ref-classes-insane`" section.
 
    :term:`WKS_FILE`
       Specifies the location of the Wic kickstart file that is used by the