manuals: simplify references to classes

Now that .bbclass is removed from class section titles.
We can now have, for example, :ref:`ref-classes-insane`
instead of :ref:`insane <ref-classes-insane>`.

Then, when necessary, rework paragraphs so that they
have lines of even length, not exceeding 80 characters.

(From yocto-docs rev: e76190e3be78c1e483bec0469f1e437dbf8f3791)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Suggested-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/bsp-guide/bsp.rst

@@ -1365,7 +1365,7 @@ Project Reference Manual.
 
 -  :term:`IMAGE_INSTALL`:
    Specifies packages to install into an image through the
-   :ref:`image <ref-classes-image>` class. Recipes
+   :ref:`ref-classes-image` class. Recipes
    use the :term:`IMAGE_INSTALL` variable.
 
 -  ``do_image_wic[depends]``: A task that is constructed during the

documentation/dev-manual/build-quality.rst

@@ -14,13 +14,11 @@ has already been built when the software is building, the software will
 link to the built library and that library will be pulled into your
 image along with the new software even if you did not want the library.
 
-The :ref:`buildhistory <ref-classes-buildhistory>`
-class helps you maintain the quality of your build output. You
-can use the class to highlight unexpected and possibly unwanted changes
-in the build output. When you enable build history, it records
-information about the contents of each package and image and then
-commits that information to a local Git repository where you can examine
-the information.
+The :ref:`ref-classes-buildhistory` class helps you maintain the quality of
+your build output. You can use the class to highlight unexpected and possibly
+unwanted changes in the build output. When you enable build history, it records
+information about the contents of each package and image and then commits that
+information to a local Git repository where you can examine the information.
 
 The remainder of this section describes the following:
 

documentation/dev-manual/building.rst

@@ -295,8 +295,8 @@ Follow these steps to create an :term:`Initramfs` image:
    recipe, you should use :term:`PACKAGE_INSTALL` rather than
    :term:`IMAGE_INSTALL`. :term:`PACKAGE_INSTALL` gives more direct control of
    what is added to the image as compared to the defaults you might not
-   necessarily want that are set by the :ref:`image <ref-classes-image>`
-   or :ref:`core-image <ref-classes-core-image>` classes.
+   necessarily want that are set by the :ref:`ref-classes-image`
+   or :ref:`ref-classes-core-image` classes.
 
 #. *Build the Kernel Image and the Initramfs Image:* Build your kernel
    image using BitBake. Because the :term:`Initramfs` image recipe is a
@@ -683,7 +683,7 @@ your tunings to best consider build times and package feed maintenance.
    A recipe that just generates scripts can enable "all" architecture
    because there are no binaries to build. To specifically enable "all"
    architecture, be sure your recipe inherits the
-   :ref:`allarch <ref-classes-allarch>` class.
+   :ref:`ref-classes-allarch` class.
    This class is useful for "all" architectures because it configures
    many variables so packages can be used across multiple architectures.
 
@@ -796,7 +796,7 @@ where the development occurs. You want the recipe's
 the external directory and use it as is, not copy it.
 
 To build from software that comes from an external source, all you need to do
-is inherit the :ref:`externalsrc <ref-classes-externalsrc>` class and then set
+is inherit the :ref:`ref-classes-externalsrc` class and then set
 the :term:`EXTERNALSRC` variable to point to your external source code. Here
 are the statements to put in your ``local.conf`` file::
 
@@ -812,8 +812,7 @@ This next example shows how to accomplish the same thing by setting
 .. note::
 
    In order for these settings to take effect, you must globally or
-   locally inherit the :ref:`externalsrc <ref-classes-externalsrc>`
-   class.
+   locally inherit the :ref:`ref-classes-externalsrc` class.
 
 By default, :ref:`ref-classes-externalsrc` builds the source code in a
 directory separate from the external source directory as specified by
@@ -881,14 +880,14 @@ directory:
 
 #. *Using Local Files Only:* Inside your ``local.conf`` file, add the
    :term:`SOURCE_MIRROR_URL` variable, inherit the
-   :ref:`own-mirrors <ref-classes-own-mirrors>` class, and use the
+   :ref:`ref-classes-own-mirrors` class, and use the
    :term:`BB_NO_NETWORK` variable to your ``local.conf``::
 
       SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/"
       INHERIT += "own-mirrors"
       BB_NO_NETWORK = "1"
 
-   The :term:`SOURCE_MIRROR_URL` and :ref:`own-mirrors <ref-classes-own-mirrors>`
+   The :term:`SOURCE_MIRROR_URL` and :ref:`ref-classes-own-mirrors`
    class set up the system to use the downloads directory as your "own
    mirror". Using the :term:`BB_NO_NETWORK` variable makes sure that
    BitBake's fetching process in step 3 stays local, which means files

documentation/dev-manual/debugging.rst

@@ -153,7 +153,7 @@ In addition to variable values, the output of the ``bitbake -e`` and
    classes included globally, recursively listing the files they include
    or inherit in turn. Much of the behavior of the OpenEmbedded build
    system (including the behavior of the :ref:`ref-manual/tasks:normal recipe build tasks`) is
-   implemented in the :ref:`base <ref-classes-base>` class and the
+   implemented in the :ref:`ref-classes-base` class and the
    classes it inherits, rather than being built into BitBake itself.
 
 -  After the variable values, all functions appear in the output. For
@@ -196,8 +196,7 @@ Following are a few of the available ``oe-pkgdata-util`` subcommands.
       which contains the files stored in that package.
 
       If you want to inspect the ``${WORKDIR}/packages-split``
-      directory, make sure that
-      :ref:`rm_work <ref-classes-rm-work>` is not
+      directory, make sure that :ref:`ref-classes-rm-work` is not
       enabled when you build the recipe.
 
 -  ``oe-pkgdata-util find-path path ...``: Lists the names of
@@ -598,8 +597,7 @@ log to ``${T}/log.do_``\ `task`, and can also log to standard output
 
 The same logging functions are also available in shell functions, under
 the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``,
-and ``bbfatal``. The
-:ref:`logging <ref-classes-logging>` class
+and ``bbfatal``. The :ref:`ref-classes-logging` class
 implements these functions. See that class in the ``meta/classes``
 folder of the :term:`Source Directory` for information.
 

documentation/dev-manual/disk-space.rst

@@ -14,8 +14,7 @@ the :term:`Build Directory`::
 
 Adding this statement deletes the work directory used for
 building a recipe once the recipe is built. For more information on
-"rm_work", see the
-:ref:`rm_work <ref-classes-rm-work>` class in the
+"rm_work", see the :ref:`ref-classes-rm-work` class in the
 Yocto Project Reference Manual.
 
 Purging Duplicate Shared State Cache Files

documentation/dev-manual/error-reporting-tool.rst

@@ -27,9 +27,9 @@ Enabling and Using the Tool
 ===========================
 
 By default, the error reporting tool is disabled. You can enable it by
-inheriting the :ref:`report-error <ref-classes-report-error>`
-class by adding the following statement to the end of your
-``local.conf`` file in your :term:`Build Directory`::
+inheriting the :ref:`ref-classes-report-error` class by adding the
+following statement to the end of your ``local.conf`` file in your
+:term:`Build Directory`::
 
    INHERIT += "report-error"
 

documentation/dev-manual/gobject-introspection.rst

@@ -39,9 +39,7 @@ Enabling the Generation of Introspection Data
 Enabling the generation of introspection data (GIR files) in your
 library package involves the following:
 
-#. Inherit the
-   :ref:`gobject-introspection <ref-classes-gobject-introspection>`
-   class.
+#. Inherit the :ref:`ref-classes-gobject-introspection` class.
 
 #. Make sure introspection is not disabled anywhere in the recipe or
    from anything the recipe includes. Also, make sure that

documentation/dev-manual/licenses.rst

@@ -325,13 +325,12 @@ and not just the source used in the released image. It will include
 toolchain source, and other artifacts, which you would not generally
 release. However, the more serious issue for most companies is
 accidental release of proprietary software. The Yocto Project provides
-an :ref:`archiver <ref-classes-archiver>` class to
-help avoid some of these concerns.
+an :ref:`ref-classes-archiver` class to help avoid some of these concerns.
 
-Before you employ :term:`DL_DIR` or the :ref:`archiver <ref-classes-archiver>` class, you need to
-decide how you choose to provide source. The source :ref:`archiver <ref-classes-archiver>` class
-can generate tarballs and SRPMs and can create them with various levels
-of compliance in mind.
+Before you employ :term:`DL_DIR` or the :ref:`ref-classes-archiver` class, you
+need to decide how you choose to provide source. The source
+:ref:`ref-classes-archiver` class can generate tarballs and SRPMs and can
+create them with various levels of compliance in mind.
 
 One way of doing this (but certainly not the only way) is to release
 just the source as a tarball. You can do this by adding the following to
@@ -417,8 +416,8 @@ generation are included on your image.
    adds a separate package and an upgrade path for adding licenses to an
    image.
 
-As the source :ref:`archiver <ref-classes-archiver>` class has already archived the original
-unmodified source that contains the license files, you would have
+As the source :ref:`ref-classes-archiver` class has already archived the
+original unmodified source that contains the license files, you would have
 already met the requirements for inclusion of the license information
 with source as defined by the GPL and other open source licenses.
 
@@ -488,8 +487,8 @@ mechanisms as well as explicitly included in the image recipe with
 :term:`IMAGE_INSTALL`, and depends on a static linked library recipe B
 (``DEPENDS += "B"``), package B will neither appear in the generated license
 manifest nor in the generated source tarballs.  This occurs as the
-:ref:`license <ref-classes-license>` and :ref:`archiver <ref-classes-archiver>`
-classes assume that only packages included via :term:`RDEPENDS` or :term:`RRECOMMENDS`
+:ref:`ref-classes-license` and :ref:`ref-classes-archiver` classes assume that
+only packages included via :term:`RDEPENDS` or :term:`RRECOMMENDS`
 end up in the image.
 
 As a result, potential obligations regarding license compliance for package B

documentation/dev-manual/new-recipe.rst

@@ -565,7 +565,7 @@ your software is built:
    need to modify the configuration.
 
    When using Autotools, your recipe needs to inherit the
-   :ref:`autotools <ref-classes-autotools>` class and it does not have to
+   :ref:`ref-classes-autotools` class and it does not have to
    contain a :ref:`ref-tasks-configure` task. However, you might still want to
    make some adjustments. For example, you can set :term:`EXTRA_OECONF` or
    :term:`PACKAGECONFIG_CONFARGS` to pass any needed configure options that
@@ -576,7 +576,7 @@ your software is built:
    need to modify the configuration.
 
    When you use CMake, your recipe needs to inherit the
-   :ref:`cmake <ref-classes-cmake>` class and it does not have to contain a
+   :ref:`ref-classes-cmake` class and it does not have to contain a
    :ref:`ref-tasks-configure` task. You can make some adjustments by setting
    :term:`EXTRA_OECMAKE` to pass any needed configure options that are
    specific to the recipe.
@@ -712,7 +712,7 @@ Here are some common issues that cause failures.
    ":ref:`dev-manual/debugging:debugging parallel make races`" section.
 
 -  *Improper host path usage:* This failure applies to recipes building
-   for the target or ":ref:`nativesdk <ref-classes-nativesdk>`" only. The
+   for the target or ":ref:`ref-classes-nativesdk`" only. The
    failure occurs when the compilation process uses improper headers,
    libraries, or other files from the host system when cross-compiling for
    the target.
@@ -807,14 +807,13 @@ installed correctly.
       re-execute :ref:`ref-tasks-install` if needed.
 
    -  ``oe_runmake install``, which can be run directly or can be run
-      indirectly by the
-      :ref:`autotools <ref-classes-autotools>` and
-      :ref:`cmake <ref-classes-cmake>` classes,
-      runs ``make install`` in parallel. Sometimes, a Makefile can have
-      missing dependencies between targets that can result in race
-      conditions. If you experience intermittent failures during
-      :ref:`ref-tasks-install`, you might be able to work around them by disabling
-      parallel Makefile installs by adding the following to the recipe::
+      indirectly by the :ref:`ref-classes-autotools` and
+      :ref:`ref-classes-cmake` classes, runs ``make install`` in parallel.
+      Sometimes, a Makefile can have missing dependencies between targets that
+      can result in race conditions. If you experience intermittent failures
+      during :ref:`ref-tasks-install`, you might be able to work around them by
+      disabling parallel Makefile installs by adding the following to the
+      recipe::
 
          PARALLEL_MAKEINST = ""
 
@@ -854,7 +853,7 @@ different ways:
    shutdown of all other programs.
 
    To enable a service using SysVinit, your recipe needs to inherit the
-   :ref:`update-rc.d <ref-classes-update-rc.d>` class. The class helps
+   :ref:`ref-classes-update-rc.d` class. The class helps
    facilitate safely installing the package on the target.
 
    You will need to set the
@@ -870,7 +869,7 @@ different ways:
    https://freedesktop.org/wiki/Software/systemd/.
 
    To enable a service using systemd, your recipe needs to inherit the
-   :ref:`systemd <ref-classes-systemd>` class. See the ``systemd.bbclass`` file
+   :ref:`ref-classes-systemd` class. See the ``systemd.bbclass`` file
    located in your :term:`Source Directory` section for more information.
 
 Packaging
@@ -886,14 +885,12 @@ take. The following list describes the process:
    other logical components that should be split out. The :ref:`ref-tasks-package`
    task ensures that files are split up and packaged correctly.
 
--  *Running QA Checks*: The
-   :ref:`insane <ref-classes-insane>` class adds a
+-  *Running QA Checks*: The :ref:`ref-classes-insane` class adds a
    step to the package generation process so that output quality
    assurance checks are generated by the OpenEmbedded build system. This
    step performs a range of checks to be sure the build's output is free
    of common problems that show up during runtime. For information on
-   these checks, see the
-   :ref:`insane <ref-classes-insane>` class and
+   these checks, see the :ref:`ref-classes-insane` class and
    the ":ref:`ref-manual/qa-checks:qa error and warning messages`"
    chapter in the Yocto Project Reference Manual.
 
@@ -934,8 +931,7 @@ take. The following list describes the process:
    On the other hand, if the recipe produces packages that do not
    contain anything specific to the target machine or architecture at
    all (e.g. recipes that simply package script files or configuration
-   files), you should use the
-   :ref:`allarch <ref-classes-allarch>` class to
+   files), you should use the :ref:`ref-classes-allarch` class to
    do this for you by adding this to your recipe::
 
       inherit allarch
@@ -1002,18 +998,16 @@ same functionality, you can use a virtual provider (i.e. ``virtual/*``)
 as a placeholder for the actual provider. The actual provider is
 determined at build-time.
 
-A common scenario where a virtual provider is used would be for the
-kernel recipe. Suppose you have three kernel recipes whose
-:term:`PN` values map to ``kernel-big``,
-``kernel-mid``, and ``kernel-small``. Furthermore, each of these recipes
-in some way uses a :term:`PROVIDES`
-statement that essentially identifies itself as being able to provide
-``virtual/kernel``. Here is one way through the
-:ref:`kernel <ref-classes-kernel>` class::
+A common scenario where a virtual provider is used would be for the kernel
+recipe. Suppose you have three kernel recipes whose :term:`PN` values map to
+``kernel-big``, ``kernel-mid``, and ``kernel-small``. Furthermore, each of
+these recipes in some way uses a :term:`PROVIDES` statement that essentially
+identifies itself as being able to provide ``virtual/kernel``. Here is one way
+through the :ref:`ref-classes-kernel` class::
 
    PROVIDES += "virtual/kernel"
 
-Any recipe that inherits the :ref:`kernel <ref-classes-kernel>` class is
+Any recipe that inherits the :ref:`ref-classes-kernel` class is
 going to utilize a :term:`PROVIDES` statement that identifies that recipe as
 being able to provide the ``virtual/kernel`` item.
 
@@ -1223,7 +1217,7 @@ Autotooled Package
 
 Applications that use Autotools such as ``autoconf`` and ``automake``
 require a recipe that has a source archive listed in :term:`SRC_URI` and
-also inherit the :ref:`autotools <ref-classes-autotools>` class,
+also inherit the :ref:`ref-classes-autotools` class,
 which contains the definitions of all the steps needed to build an
 Autotool-based application. The result of the build is automatically
 packaged. And, if the application uses NLS for localization, packages
@@ -1353,24 +1347,19 @@ could lead to compatibility problems with ABI in the future. However,
 sometimes you have no choice.
 
 The easiest solution is to create a recipe that uses the
-:ref:`bin_package <ref-classes-bin-package>` class
-and to be sure that you are using default locations for build artifacts.
-In most cases, the :ref:`bin_package <ref-classes-bin-package>` class handles "skipping" the
-configure and compile steps as well as sets things up to grab packages
-from the appropriate area. In particular, this class sets ``noexec`` on
-both the :ref:`ref-tasks-configure`
-and :ref:`ref-tasks-compile` tasks,
-sets ``FILES:${PN}`` to "/" so that it picks up all files, and sets up a
-:ref:`ref-tasks-install` task, which
-effectively copies all files from ``${S}`` to ``${D}``. The
-:ref:`bin_package <ref-classes-bin-package>` class works well when the files extracted into ``${S}``
-are already laid out in the way they should be laid out on the target.
-For more information on these variables, see the
-:term:`FILES`,
-:term:`PN`,
-:term:`S`, and
-:term:`D` variables in the Yocto Project
-Reference Manual's variable glossary.
+:ref:`ref-classes-bin-package` class and to be sure that you are using default
+locations for build artifacts.  In most cases, the
+:ref:`ref-classes-bin-package` class handles "skipping" the configure and
+compile steps as well as sets things up to grab packages from the appropriate
+area. In particular, this class sets ``noexec`` on both the
+:ref:`ref-tasks-configure` and :ref:`ref-tasks-compile` tasks, sets
+``FILES:${PN}`` to "/" so that it picks up all files, and sets up a
+:ref:`ref-tasks-install` task, which effectively copies all files from ``${S}``
+to ``${D}``. The :ref:`ref-classes-bin-package` class works well when the files
+extracted into ``${S}`` are already laid out in the way they should be laid out
+on the target. For more information on these variables, see the :term:`FILES`,
+:term:`PN`, :term:`S`, and :term:`D` variables in the Yocto Project Reference
+Manual's variable glossary.
 
 .. note::
 
@@ -1388,7 +1377,7 @@ Reference Manual's variable glossary.
       section in the Yocto Project Overview and Concepts Manual for more
       information.
 
-If you cannot use the :ref:`bin_package <ref-classes-bin-package>` class, you need to be sure you are
+If you cannot use the :ref:`ref-classes-bin-package` class, you need to be sure you are
 doing the following:
 
 -  Create a recipe where the

documentation/dev-manual/packages.rst

@@ -643,8 +643,7 @@ Lighttpd, or Nginx), take the appropriate steps to do so.
 From within the :term:`Build Directory` where you have built an image based on
 your packaging choice (i.e. the :term:`PACKAGE_CLASSES` setting), simply start
 the server. The following example assumes a :term:`Build Directory` of ``poky/build``
-and a :term:`PACKAGE_CLASSES` setting of
-":ref:`package_rpm <ref-classes-package_rpm>`"::
+and a :term:`PACKAGE_CLASSES` setting of ":ref:`ref-classes-package_rpm`"::
 
    $ cd poky/build/tmp/deploy/rpm
    $ python3 -m http.server
@@ -909,8 +908,8 @@ see the :yocto_wiki:`Ptest </Ptest>` wiki page.
 
 .. note::
 
-   A recipe is "ptest-enabled" if it inherits the
-   :ref:`ptest <ref-classes-ptest>` class.
+   A recipe is "ptest-enabled" if it inherits the :ref:`ref-classes-ptest`
+   class.
 
 Adding ptest to Your Build
 --------------------------
@@ -940,7 +939,7 @@ In order to enable a recipe to run installed ptests on target hardware,
 you need to prepare the recipes that build the packages you want to
 test. Here is what you have to do for each recipe:
 
--  *Be sure the recipe inherits the* :ref:`ptest <ref-classes-ptest>` *class:*
+-  *Be sure the recipe inherits the* :ref:`ref-classes-ptest` *class:*
    Include the following line in each recipe::
 
       inherit ptest
@@ -991,7 +990,7 @@ test. Here is what you have to do for each recipe:
    special configurations prior to compiling the test code, you must
    insert a ``do_configure_ptest`` function into the recipe.
 
--  *Install the test suite:* The :ref:`ptest <ref-classes-ptest>` class
+-  *Install the test suite:* The :ref:`ref-classes-ptest` class
    automatically copies the file ``run-ptest`` to the target and then runs make
    ``install-ptest`` to run the tests. If this is not enough, you need
    to create a ``do_install_ptest`` function and make sure it gets
@@ -1145,9 +1144,8 @@ Here are three key points in the previous example:
    sub-module's license is unavailable, the sub-module's name appears in
    the comments.
 
--  The ``inherit npm`` statement causes the
-   :ref:`npm <ref-classes-npm>` class to package
-   up all the modules.
+-  The ``inherit npm`` statement causes the :ref:`ref-classes-npm` class to
+   package up all the modules.
 
 You can run the following command to build the ``cute-files`` package::
 

documentation/dev-manual/quilt.rst

@@ -12,7 +12,7 @@ form of a patch all using Quilt.
 .. note::
 
    With regard to preserving changes to source files, if you clean a
-   recipe or have :ref:`rm_work <ref-classes-rm-work>` enabled, the
+   recipe or have :ref:`ref-classes-rm-work` enabled, the
    :ref:`devtool workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
    as described in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual is a safer
@@ -61,7 +61,7 @@ Follow these general steps:
       once you run the :ref:`ref-tasks-clean` or :ref:`ref-tasks-cleanall`
       tasks using BitBake (i.e. ``bitbake -c clean package`` and
       ``bitbake -c cleanall package``). Modifications will also disappear if
-      you use the :ref:`rm_work <ref-classes-rm-work>` feature as described in
+      you use the :ref:`ref-classes-rm-work` feature as described in
       the ":ref:`dev-manual/disk-space:conserving disk space during builds`"
       section.
 

documentation/dev-manual/read-only-rootfs.rst

@@ -76,7 +76,7 @@ from running during root filesystem creation:
    native tools, which run on the host system, to accomplish the same
    tasks, or by alternatively running the processes under QEMU, which
    has the ``qemu_run_binary`` function. For more information, see the
-   :ref:`qemu <ref-classes-qemu>` class.
+   :ref:`ref-classes-qemu` class.
 
 Areas With Write Access
 =======================

documentation/dev-manual/runtime-testing.rst

@@ -332,8 +332,8 @@ You can start the tests automatically or manually:
       bitbake core-image-sato
 
 -  *Manually running tests:* To manually run the tests, first globally
-   inherit the :ref:`testimage <ref-classes-testimage>` class
-   by editing your ``local.conf`` file::
+   inherit the :ref:`ref-classes-testimage` class by editing your
+   ``local.conf`` file::
 
       INHERIT += "testimage"
 

documentation/dev-manual/sbom.rst

@@ -26,7 +26,7 @@ assessments, as all the components used in the Software Supply Chain are listed.
 
 The OpenEmbedded build system doesn't generate such information by default.
 To make this happen, you must inherit the
-:ref:`create-spdx <ref-classes-create-spdx>` class from a configuration file::
+:ref:`ref-classes-create-spdx` class from a configuration file::
 
    INHERIT += "create-spdx"
 
@@ -39,7 +39,7 @@ containing an index of JSON :term:`SPDX` files for individual recipes, together
 with an ``IMAGE-MACHINE.spdx.tar.zst`` compressed archive containing all such
 files.
 
-The :ref:`create-spdx <ref-classes-create-spdx>` class offers options to include
+The :ref:`ref-classes-create-spdx` class offers options to include
 more information in the output :term:`SPDX` data, such as making the generated
 files more human readable (:term:`SPDX_PRETTY`), adding compressed archives of
 the files in the generated target packages (:term:`SPDX_ARCHIVE_PACKAGED`),

documentation/dev-manual/securing-images.rst

@@ -128,11 +128,9 @@ system to make your images more secure:
    service type users). When you set up passwords for multiple images or
    users, you should not duplicate passwords.
 
-   To set up passwords, use the
-   :ref:`extrausers <ref-classes-extrausers>`
-   class, which is the preferred method. For an example on how to set up
-   both root and user passwords, see the
-   ":ref:`ref-classes-extrausers`" section.
+   To set up passwords, use the :ref:`ref-classes-extrausers` class, which
+   is the preferred method. For an example on how to set up both root and
+   user passwords, see the ":ref:`ref-classes-extrausers`" section.
 
    .. note::
 

documentation/dev-manual/speeding-up-build.rst

@@ -61,8 +61,7 @@ Following are additional factors that can affect build speed:
    file system on the principle that if there was a significant failure,
    the :term:`Build Directory` contents could easily be rebuilt.
 
--  Inheriting the
-   :ref:`rm_work <ref-classes-rm-work>` class:
+-  Inheriting the :ref:`ref-classes-rm-work` class:
    Inheriting this class has shown to speed up builds due to
    significantly lower amounts of data stored in the data cache as well
    as on disk. Inheriting this class also makes cleanup of

documentation/dev-manual/upgrading-recipes.rst

@@ -113,8 +113,7 @@ The following steps describe how to set up the AUH utility:
       ``upgrade-helper/work/recipe/buildhistory-diff.txt`` file found in
       your :term:`Build Directory`.
 
-   -  If you want to enable testing through the
-      :ref:`testimage <ref-classes-testimage>`
+   -  If you want to enable testing through the :ref:`ref-classes-testimage`
       class, which is optional, you need to have the following set in
       your ``conf/local.conf`` file::
 

documentation/dev-manual/vulnerabilities.rst

@@ -27,8 +27,9 @@ patches to fix them, see ":ref:`dev-manual/changes:submitting a change to the yo
 Vulnerability check at build time
 =================================
 
-To enable a check for CVE security vulnerabilities using :ref:`cve-check <ref-classes-cve-check>` in the specific image
-or target you are building, add the following setting to your configuration::
+To enable a check for CVE security vulnerabilities using
+:ref:`ref-classes-cve-check` in the specific image or target you are building,
+add the following setting to your configuration::
 
    INHERIT += "cve-check"
 
@@ -100,7 +101,7 @@ It is also possible to check the CVE status of individual packages as follows::
 Fixing CVE product name and version mappings
 ============================================
 
-By default, :ref:`cve-check <ref-classes-cve-check>` uses the recipe name :term:`BPN` as CVE
+By default, :ref:`ref-classes-cve-check` uses the recipe name :term:`BPN` as CVE
 product name when querying the CVE database. If this mapping contains false positives, e.g.
 some reported CVEs are not for the software component in question, or false negatives like
 some CVEs are not found to impact the recipe when they should, then the problems can be
@@ -167,8 +168,7 @@ the :term:`CVE_CHECK_SKIP_RECIPE` variable.
 Implementation details
 ======================
 
-Here's what the :ref:`cve-check <ref-classes-cve-check>` class does to
-find unpatched CVE IDs.
+Here's what the :ref:`ref-classes-cve-check` class does to find unpatched CVE IDs.
 
 First the code goes through each patch file provided by a recipe. If a valid CVE ID
 is found in the name of the file, the corresponding CVE is considered as patched.

documentation/dev-manual/wic.rst

@@ -59,8 +59,7 @@ this information is required to use Wic, you might find it interesting.
 
 -  Wic is a completely independent standalone utility that initially
    provides easier-to-use and more flexible replacements for an existing
-   functionality in OE-Core's
-   :ref:`image-live <ref-classes-image-live>`
+   functionality in OE-Core's :ref:`ref-classes-image-live`
    class. The difference between Wic and those examples is that with Wic
    the functionality of those scripts is implemented by a
    general-purpose partitioning language, which is based on Redhat

documentation/kernel-dev/common.rst

@@ -1685,12 +1685,10 @@ looks much like the one provided with the ``hello-mod`` template::
    ...
 
 The important point to note here is the :term:`KERNEL_SRC` variable. The
-:ref:`module <ref-classes-module>` class sets this variable and the
-:term:`KERNEL_PATH` variable to
-``${STAGING_KERNEL_DIR}`` with the necessary Linux kernel build
-information to build modules. If your module ``Makefile`` uses a
-different variable, you might want to override the
-:ref:`ref-tasks-compile` step, or
+:ref:`ref-classes-module` class sets this variable and the :term:`KERNEL_PATH`
+variable to ``${STAGING_KERNEL_DIR}`` with the necessary Linux kernel build
+information to build modules. If your module ``Makefile`` uses a different
+variable, you might want to override the :ref:`ref-tasks-compile` step, or
 create a patch to the ``Makefile`` to work with the more typical
 :term:`KERNEL_SRC` or :term:`KERNEL_PATH` variables.
 

documentation/migration-guides/migration-1.3.rst

@@ -91,11 +91,11 @@ consistency.
 nativesdk
 ~~~~~~~~~
 
-The suffix ``nativesdk`` is now implemented as a prefix, which simplifies a
-lot of the packaging code for :ref:`nativesdk <ref-classes-nativesdk>` recipes.
-All custom :ref:`nativesdk <ref-classes-nativesdk>` recipes, which are
-relocatable packages that are native to :term:`SDK_ARCH`, and any references
-need to be updated to use ``nativesdk-*`` instead of ``*-nativesdk``.
+The suffix ``nativesdk`` is now implemented as a prefix, which simplifies a lot
+of the packaging code for :ref:`ref-classes-nativesdk` recipes.  All custom
+:ref:`ref-classes-nativesdk` recipes, which are relocatable packages that are
+native to :term:`SDK_ARCH`, and any references need to be updated to use
+``nativesdk-*`` instead of ``*-nativesdk``.
 
 .. _migration-1.3-task-recipes:
 
@@ -109,7 +109,7 @@ automatic upgrade path for most packages. However, you should update
 references in your own recipes and configurations as they could be
 removed in future releases. You should also rename any custom ``task-*``
 recipes to ``packagegroup-*``, and change them to inherit
-:ref:`packagegroup <ref-classes-packagegroup>` instead of ``task``, as well
+:ref:`ref-classes-packagegroup` instead of ``task``, as well
 as taking the opportunity to remove anything now handled by
 :ref:`ref-classes-packagegroup`, such as providing ``-dev`` and ``-dbg``
 packages, setting :term:`LIC_FILES_CHKSUM`, and so forth. See the

documentation/migration-guides/migration-1.5.rst

@@ -95,9 +95,8 @@ The following changes have been made to the package QA checks:
    this file within :ref:`ref-tasks-install` if "make
    install" is installing it.
 
--  If you are using the :ref:`buildhistory <ref-classes-buildhistory>` class,
-   the check for the package
-   version going backwards is now controlled using a standard QA check.
+-  If you are using the :ref:`ref-classes-buildhistory` class, the check for the
+   package version going backwards is now controlled using a standard QA check.
    Thus, if you have customized your :term:`ERROR_QA` or :term:`WARN_QA` values
    and still wish to have this check performed, you should add
    "version-going-backwards" to your value for one or the other
@@ -131,7 +130,7 @@ The following directory changes exist:
    it easier to delete :term:`TMPDIR` and preserve the build history.
    Additionally, data for produced SDKs is now split by :term:`IMAGE_NAME`.
 
--  When :ref:`buildhistory <ref-classes-buildhistory>` is enabled, its output
+-  When :ref:`ref-classes-buildhistory` is enabled, its output
    is now written under the :term:`Build Directory` rather than :term:`TMPDIR`.
    Doing so makes it easier to delete :term:`TMPDIR` and preserve the build
    history. Additionally, data for produced SDKs is now split by :term:`IMAGE_NAME`.
@@ -223,7 +222,7 @@ Task Recipes
 The previously deprecated ``task.bbclass`` has now been dropped. For
 recipes that previously inherited from this class, you should rename
 them from ``task-*`` to ``packagegroup-*`` and inherit
-:ref:`packagegroup <ref-classes-packagegroup>` instead.
+:ref:`ref-classes-packagegroup` instead.
 
 For more information, see the ":ref:`ref-classes-packagegroup`" section.
 

documentation/migration-guides/migration-1.6.rst

@@ -11,9 +11,8 @@ Project 1.6 Release (codename "daisy") from the prior release.
 ``archiver`` Class
 ------------------
 
-The :ref:`archiver <ref-classes-archiver>` class has been rewritten
-and its configuration has been simplified. For more details on the
-source archiver, see the
+The :ref:`ref-classes-archiver` class has been rewritten and its configuration
+has been simplified. For more details on the source archiver, see the
 ":ref:`dev-manual/licenses:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
@@ -224,7 +223,7 @@ Package Tests (ptest) are built but not installed by default. For
 information on using Package Tests, see the
 ":ref:`dev-manual/packages:testing packages with ptest`" section in the
 Yocto Project Development Tasks Manual. For information on the
-:ref:`ptest <ref-classes-ptest>` class, see the ":ref:`ref-classes-ptest`"
+:ref:`ref-classes-ptest` class, see the ":ref:`ref-classes-ptest`"
 section.
 
 .. _migration-1.6-build-changes:
@@ -234,13 +233,13 @@ Build Changes
 
 Separate build and source directories have been enabled by default for
 selected recipes where it is known to work and for all
-recipes that inherit the :ref:`cmake <ref-classes-cmake>` class. In
-future releases the :ref:`autotools <ref-classes-autotools>` class
+recipes that inherit the :ref:`ref-classes-cmake` class. In
+future releases the :ref:`ref-classes-autotools` class
 will enable a separate :term:`Build Directory` by default as well. Recipes
 building Autotools-based software that fails to build with a separate
 :term:`Build Directory` should be changed to inherit from the
 :ref:`autotools-brokensep <ref-classes-autotools>` class instead of
-the :ref:`autotools <ref-classes-autotools>` or ``autotools_stage`` classes.
+the :ref:`ref-classes-autotools` or ``autotools_stage`` classes.
 
 .. _migration-1.6-building-qemu-native:
 

documentation/migration-guides/migration-1.7.rst

@@ -41,13 +41,11 @@ section for more information.
 Autotools Class Changes
 -----------------------
 
-The following :ref:`autotools <ref-classes-autotools>` class changes
-occurred:
+The following :ref:`ref-classes-autotools` class changes occurred:
 
 -  *A separate :term:`Build Directory` is now used by default:* The
-   :ref:`autotools <ref-classes-autotools>` class has been
-   changed to use a directory for building
-   (:term:`B`), which is separate from the source directory
+   :ref:`ref-classes-autotools` class has been changed to use a directory for
+   building (:term:`B`), which is separate from the source directory
    (:term:`S`). This is commonly referred to as ``B != S``, or
    an out-of-tree build.
 
@@ -56,9 +54,8 @@ occurred:
    However, if the software is not capable of being built in this
    manner, you will need to either patch the software so that it can
    build separately, or you will need to change the recipe to inherit
-   the :ref:`autotools-brokensep <ref-classes-autotools>` class
-   instead of the :ref:`autotools <ref-classes-autotools>`
-   or ``autotools_stage`` classes.
+   the :ref:`autotools-brokensep <ref-classes-autotools>` class instead
+   of the :ref:`ref-classes-autotools` or ``autotools_stage`` classes.
 
 -  The ``--foreign`` option is no longer passed to ``automake`` when
    running ``autoconf``: This option tells ``automake`` that a

documentation/migration-guides/migration-1.8.rst

@@ -70,17 +70,16 @@ the following::
 Kernel Build Changes
 --------------------
 
-The kernel build process was changed to place the source in a common
-shared work area and to place build artifacts separately in the source
-code tree. In theory, migration paths have been provided for most common
-usages in kernel recipes but this might not work in all cases. In
-particular, users need to ensure that ``${S}`` (source files) and
-``${B}`` (build artifacts) are used correctly in functions such as
-:ref:`ref-tasks-configure` and
-:ref:`ref-tasks-install`. For kernel recipes that do not
-inherit from :ref:`kernel-yocto <ref-classes-kernel-yocto>` or include ``linux-yocto.inc``, you might
-wish to refer to the ``linux.inc`` file in the ``meta-oe`` layer for the
-kinds of changes you need to make. For reference, here is the
+The kernel build process was changed to place the source in a common shared work
+area and to place build artifacts separately in the source code tree. In theory,
+migration paths have been provided for most common usages in kernel recipes but
+this might not work in all cases. In particular, users need to ensure that
+``${S}`` (source files) and ``${B}`` (build artifacts) are used correctly in
+functions such as :ref:`ref-tasks-configure` and :ref:`ref-tasks-install`. For
+kernel recipes that do not inherit from :ref:`ref-classes-kernel-yocto` or
+include ``linux-yocto.inc``, you might wish to refer to the ``linux.inc`` file
+in the ``meta-oe`` layer for the kinds of changes you need to make. For reference,
+here is the
 :oe_git:`commit </meta-openembedded/commit/meta-oe/recipes-kernel/linux/linux.inc?id=fc7132ede27ac67669448d3d2845ce7d46c6a1ee>`
 where the ``linux.inc`` file in ``meta-oe`` was updated.
 
@@ -123,10 +122,9 @@ need to take corrective steps.
 Rebuild Improvements
 --------------------
 
-Changes have been made to the :ref:`base <ref-classes-base>`,
-:ref:`autotools <ref-classes-autotools>`, and
-:ref:`cmake <ref-classes-cmake>` classes to clean out generated files
-when the :ref:`ref-tasks-configure` task needs to be
+Changes have been made to the :ref:`ref-classes-base`,
+:ref:`ref-classes-autotools`, and :ref:`ref-classes-cmake` classes to clean out
+generated files when the :ref:`ref-tasks-configure` task needs to be
 re-executed.
 
 One of the improvements is to attempt to run "make clean" during the

documentation/migration-guides/migration-2.0.rst

@@ -216,7 +216,7 @@ modifications synchronized, it is not always obvious to developers how
 to manipulate the Metadata as compared to the source.
 
 Metadata processing has now been removed from the
-:ref:`kernel-yocto <ref-classes-kernel-yocto>` class and the external
+:ref:`ref-classes-kernel-yocto` class and the external
 Metadata repository ``yocto-kernel-cache``, which has always been used
 to seed the ``linux-yocto`` "meta" branch. This separate ``linux-yocto``
 cache repository is now the primary location for this data. Due to this

documentation/migration-guides/migration-2.1.rst

@@ -66,7 +66,7 @@ Makefile Environment Changes
 :term:`EXTRA_OEMAKE` now defaults to "" instead of
 "-e MAKEFLAGS=". Setting :term:`EXTRA_OEMAKE` to "-e MAKEFLAGS=" by default
 was a historical accident that has required many classes (e.g.
-:ref:`autotools <ref-classes-autotools>`, ``module``) and recipes to override this default in order
+:ref:`ref-classes-autotools`, ``module``) and recipes to override this default in order
 to work with sensible build systems. When upgrading to the release, you
 must edit any recipe that relies upon this old default by either setting
 :term:`EXTRA_OEMAKE` back to "-e MAKEFLAGS=" or by explicitly setting any
@@ -100,7 +100,7 @@ breaking FHS.
 ``ac_cv_sizeof_off_t`` is No Longer Cached in Site Files
 --------------------------------------------------------
 
-For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
+For recipes inheriting the :ref:`ref-classes-autotools`
 class, ``ac_cv_sizeof_off_t`` is no longer cached in the site files for
 ``autoconf``. The reason for this change is because the
 ``ac_cv_sizeof_off_t`` value is not necessarily static per architecture
@@ -108,12 +108,12 @@ as was previously assumed. Rather, the value changes based on whether
 large file support is enabled. For most software that uses ``autoconf``,
 this change should not be a problem. However, if you have a recipe that
 bypasses the standard :ref:`ref-tasks-configure` task
-from the :ref:`autotools <ref-classes-autotools>` class and the software the recipe is building
+from the :ref:`ref-classes-autotools` class and the software the recipe is building
 uses a very old version of ``autoconf``, the recipe might be incapable
 of determining the correct size of ``off_t`` during :ref:`ref-tasks-configure`.
 
 The best course of action is to patch the software as necessary to allow
-the default implementation from the :ref:`autotools <ref-classes-autotools>` class to work such
+the default implementation from the :ref:`ref-classes-autotools` class to work such
 that ``autoreconf`` succeeds and produces a working configure script,
 and to remove the overridden :ref:`ref-tasks-configure` task such that the default
 implementation does get used.
@@ -138,9 +138,8 @@ should make edits so that those tasks are after the
 after :ref:`ref-tasks-rootfs` so that your added tasks run at the correct
 time.
 
-A minor part of this restructuring is that the post-processing
-definitions and functions have been moved from the
-:ref:`image <ref-classes-image>` class to the
+A minor part of this restructuring is that the post-processing definitions and
+functions have been moved from the :ref:`ref-classes-image` class to the
 :ref:`rootfs-postcommands <ref-classes-rootfs*>` class. Functionally,
 however, they remain unchanged.
 
@@ -191,18 +190,17 @@ Class Changes
 The following classes have changed:
 
 -  ``autotools_stage``: Removed because the
-   :ref:`autotools <ref-classes-autotools>` class now provides its
+   :ref:`ref-classes-autotools` class now provides its
    functionality. Recipes that inherited from ``autotools_stage`` should
-   now inherit from :ref:`autotools <ref-classes-autotools>` instead.
+   now inherit from :ref:`ref-classes-autotools` instead.
 
 -  ``boot-directdisk``: Merged into the ``image-vm`` class. The
    ``boot-directdisk`` class was rarely directly used. Consequently,
    this change should not cause any issues.
 
--  ``bootimg``: Merged into the
-   :ref:`image-live <ref-classes-image-live>` class. The ``bootimg``
-   class was rarely directly used. Consequently, this change should not
-   cause any issues.
+-  ``bootimg``: Merged into the :ref:`ref-classes-image-live` class. The
+   ``bootimg`` class was rarely directly used. Consequently, this change should
+   not cause any issues.
 
 -  ``packageinfo``: Removed due to its limited use by the Hob UI, which
    has itself been removed.
@@ -257,14 +255,14 @@ The following changes have been made for the Poky distribution:
    not need to change anything unless you are relying on this naming
    elsewhere.
 
--  The :ref:`uninative <ref-classes-uninative>` class is now enabled
+-  The :ref:`ref-classes-uninative` class is now enabled
    by default in Poky. This class attempts to isolate the build system
    from the host distribution's C library and makes re-use of native
    shared state artifacts across different host distributions practical.
    With this class enabled, a tarball containing a pre-built C library
    is downloaded at the start of the build.
 
-   The :ref:`uninative <ref-classes-uninative>` class is enabled through the
+   The :ref:`ref-classes-uninative` class is enabled through the
    ``meta/conf/distro/include/yocto-uninative.inc`` file, which for
    those not using the Poky distribution, can include to easily enable
    the same functionality.
@@ -403,9 +401,9 @@ These additional changes exist:
    as these directories are automatically found and added.
 
 -  Inaccurate disk and CPU percentage data has been dropped from
-   :ref:`buildstats <ref-classes-buildstats>` output. This data has been replaced with
+   :ref:`ref-classes-buildstats` output. This data has been replaced with
    ``getrusage()`` data and corrected IO statistics. You will probably
-   need to update any custom code that reads the :ref:`buildstats <ref-classes-buildstats>` data.
+   need to update any custom code that reads the :ref:`ref-classes-buildstats` data.
 
 -  The ``meta/conf/distro/include/package_regex.inc`` is now deprecated.
    The contents of this file have been moved to individual recipes.

documentation/migration-guides/migration-2.3.rst

@@ -52,7 +52,7 @@ Consider the following:
    post-installation script that is installed by a function added to
    :term:`SYSROOT_PREPROCESS_FUNCS`.
 
-   For an example, see the :ref:`pixbufcache <ref-classes-pixbufcache>` class in ``meta/classes/`` in
+   For an example, see the :ref:`ref-classes-pixbufcache` class in ``meta/classes/`` in
    the :ref:`overview-manual/development-environment:yocto project source repositories`.
 
    .. note::
@@ -402,7 +402,7 @@ The following QA checks have changed:
    warning, you need to address missing runtime dependencies.
 
    For additional information, see the
-   :ref:`insane <ref-classes-insane>` class and the
+   :ref:`ref-classes-insane` class and the
    ":ref:`ref-manual/qa-checks:errors and warnings`" section.
 
 .. _migration-2.3-miscellaneous-changes:
@@ -446,7 +446,7 @@ The following miscellaneous changes have occurred:
    RSA keys only, and with recent versions of OpenSSH, which deprecates
    DSA host keys.
 
--  The :ref:`buildhistory <ref-classes-buildhistory>` class now
+-  The :ref:`ref-classes-buildhistory` class now
    correctly uses tabs as separators between all columns in
    ``installed-package-sizes.txt`` in order to aid import into other
    tools.
@@ -484,26 +484,24 @@ The following miscellaneous changes have occurred:
 
    If you need to preserve these ``.la`` files (e.g. in a custom
    distribution), you must change :term:`INHERIT_DISTRO` such that
-   ":ref:`remove-libtool <ref-classes-remove-libtool>`" is not included
+   ":ref:`ref-classes-remove-libtool`" is not included
    in the value.
 
 -  Extensible SDKs built for GCC 5+ now refuse to install on a
    distribution where the host GCC version is 4.8 or 4.9. This change
    resulted from the fact that the installation is known to fail due to
    the way the ``uninative`` shared state (sstate) package is built. See
-   the :ref:`uninative <ref-classes-uninative>` class for additional
-   information.
+   the :ref:`ref-classes-uninative` class for additional information.
 
--  All :ref:`native <ref-classes-native>` and
-   :ref:`nativesdk <ref-classes-nativesdk>` recipes now use a separate
-   :term:`DISTRO_FEATURES` value instead of sharing the value used by
-   recipes for the target, in order to avoid unnecessary rebuilds.
+-  All :ref:`ref-classes-native` and :ref:`ref-classes-nativesdk` recipes now
+   use a separate :term:`DISTRO_FEATURES` value instead of sharing the value
+   used by recipes for the target, in order to avoid unnecessary rebuilds.
 
-   The :term:`DISTRO_FEATURES` for :ref:`native <ref-classes-native>` recipes
+   The :term:`DISTRO_FEATURES` for :ref:`ref-classes-native` recipes
    is :term:`DISTRO_FEATURES_NATIVE` added to an intersection of
    :term:`DISTRO_FEATURES` and :term:`DISTRO_FEATURES_FILTER_NATIVE`.
 
-   For :ref:`nativesdk <ref-classes-nativesdk>` recipes, the corresponding
+   For :ref:`ref-classes-nativesdk` recipes, the corresponding
    variables are :term:`DISTRO_FEATURES_NATIVESDK` and
    :term:`DISTRO_FEATURES_FILTER_NATIVESDK`.
 

documentation/migration-guides/migration-2.4.rst

@@ -197,12 +197,10 @@ Kernel Device Tree Move
 -----------------------
 
 Kernel Device Tree support is now easier to enable in a kernel recipe.
-The Device Tree code has moved to a
-:ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class.
+The Device Tree code has moved to a :ref:`ref-classes-kernel-devicetree` class.
 Functionality is automatically enabled for any recipe that inherits the
-:ref:`kernel <ref-classes-kernel>` class and sets the
-:term:`KERNEL_DEVICETREE` variable. The
-previous mechanism for doing this,
+:ref:`kernel <ref-classes-kernel>` class and sets the :term:`KERNEL_DEVICETREE`
+variable. The previous mechanism for doing this,
 ``meta/recipes-kernel/linux/linux-dtb.inc``, is still available to avoid
 breakage, but triggers a deprecation warning. Future releases of the
 Yocto Project will remove ``meta/recipes-kernel/linux/linux-dtb.inc``.
@@ -271,11 +269,11 @@ The following are additional changes:
    from ``meta-poky`` to OE-Core (i.e. from
    ``meta-poky/conf/distro/include`` to ``meta/conf/distro/include``).
 
--  The :ref:`buildhistory <ref-classes-buildhistory>` class now makes
+-  The :ref:`ref-classes-buildhistory` class now makes
    a single commit per build rather than one commit per subdirectory in
    the repository. This behavior assumes the commits are enabled with
    :term:`BUILDHISTORY_COMMIT` = "1", which
-   is typical. Previously, the :ref:`buildhistory <ref-classes-buildhistory>` class made one commit
+   is typical. Previously, the :ref:`ref-classes-buildhistory` class made one commit
    per subdirectory in the repository in order to make it easier to see
    the changes for a particular subdirectory. To view a particular
    change, specify that subdirectory as the last parameter on the

documentation/migration-guides/migration-2.5.rst

@@ -139,7 +139,7 @@ The following are BitBake changes:
 -  Several explicit "run this task for all recipes in the dependency
    tree" tasks have been removed (e.g. ``fetchall``, ``checkuriall``,
    and the ``*all`` tasks provided by the ``distrodata`` and
-   :ref:`archiver <ref-classes-archiver>` classes). There is a BitBake option to complete this for
+   :ref:`ref-classes-archiver` classes). There is a BitBake option to complete this for
    any arbitrary task. For example::
 
       bitbake <target> -c fetchall
@@ -189,7 +189,7 @@ Miscellaneous Changes
 
 The following are additional changes:
 
--  The :ref:`kernel <ref-classes-kernel>` class supports building packages for multiple kernels.
+-  The :ref:`ref-classes-kernel` class supports building packages for multiple kernels.
    If your kernel recipe or ``.bbappend`` file mentions packaging at
    all, you should replace references to the kernel in package names
    with ``${KERNEL_PACKAGE_NAME}``. For example, if you disable
@@ -197,7 +197,7 @@ The following are additional changes:
    ``RDEPENDS_kernel-base = ""`` you can avoid warnings using
    ``RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""`` instead.
 
--  The :ref:`buildhistory <ref-classes-buildhistory>` class commits changes to the repository by
+-  The :ref:`ref-classes-buildhistory` class commits changes to the repository by
    default so you no longer need to set ``BUILDHISTORY_COMMIT = "1"``.
    If you want to disable commits you need to set
    ``BUILDHISTORY_COMMIT = "0"`` in your configuration.
@@ -209,12 +209,12 @@ The following are additional changes:
    maintains a full-featured BSP in the ``meta-ti`` layer. This rename
    avoids the previous name clash that existed between the two BSPs.
 
--  The :ref:`update-alternatives <ref-classes-update-alternatives>` class no longer works with SysV ``init``
+-  The :ref:`ref-classes-update-alternatives` class no longer works with SysV ``init``
    scripts because this usage has been problematic. Also, the
    ``sysklogd`` recipe no longer uses ``update-alternatives`` because it
    is incompatible with other implementations.
 
--  By default, the :ref:`cmake <ref-classes-cmake>` class uses
+-  By default, the :ref:`ref-classes-cmake` class uses
    ``ninja`` instead of ``make`` for building. This improves build
    performance. If a recipe is broken with ``ninja``, then the recipe
    can set ``OECMAKE_GENERATOR = "Unix Makefiles"`` to change back to

documentation/migration-guides/migration-2.6.rst

@@ -128,10 +128,9 @@ missing from :term:`DEPENDS`).
 
 .. note::
 
-   This change affects classes beyond just the two mentioned (i.e.
-   ``distutils`` and ``distutils3``). Any recipe that inherits ``distutils*``
-   classes are affected. For example, the ``setuptools`` and
-   :ref:`setuptools3 <ref-classes-setuptools3>`
+   This change affects classes beyond just the two mentioned (i.e. ``distutils``
+   and ``distutils3``). Any recipe that inherits ``distutils*`` classes are
+   affected. For example, the ``setuptools`` and :ref:`ref-classes-setuptools3`
    recipes are affected since they inherit the ``distutils*`` classes.
 
 Fetching these types of dependencies that are not provided in the
@@ -315,12 +314,11 @@ This section provides information about automatic testing changes:
    exists and has been replaced by the
    :term:`TESTIMAGE_AUTO` variable.
 
--  Inheriting the :ref:`testimage <ref-classes-testimage>` and
-   :ref:`testsdk <ref-classes-testsdk>` classes: best practices now dictate
-   that you use the :term:`IMAGE_CLASSES` variable rather than the
-   :term:`INHERIT` variable when you inherit the
-   :ref:`testimage <ref-classes-testimage>` and
-   :ref:`testsdk <ref-classes-testsdk>` classes used for automatic testing.
+-  Inheriting the :ref:`ref-classes-testimage` and :ref:`ref-classes-testsdk`
+   classes: best practices now dictate that you use the :term:`IMAGE_CLASSES`
+   variable rather than the :term:`INHERIT` variable when you inherit the
+   :ref:`ref-classes-testimage` and :ref:`ref-classes-testsdk` classes used
+   for automatic testing.
 
 .. _migration-2.6-openssl-changes:
 

documentation/migration-guides/migration-2.7.rst

@@ -174,8 +174,7 @@ The following miscellaneous changes occurred:
 -  ``base/pixbufcache``: Obsolete ``sstatecompletions`` code has been
    removed.
 
--  :ref:`native <ref-classes-native>` class:
-   :term:`RDEPENDS` handling has been enabled.
+-  :ref:`ref-classes-native` class: :term:`RDEPENDS` handling has been enabled.
 
 -  ``inetutils``: This recipe has rsh disabled.
 

documentation/migration-guides/migration-3.0.rst

@@ -49,7 +49,7 @@ The following recipes have been removed.
 -  ``core-image-lsb-sdk``: Part of removed LSB support.
 
 -  ``cve-check-tool``: Functionally replaced by the ``cve-update-db``
-   recipe and :ref:`cve-check <ref-classes-cve-check>` class.
+   recipe and :ref:`ref-classes-cve-check` class.
 
 -  ``eglinfo``: No longer maintained. ``eglinfo`` from ``mesa-demos`` is
    an adequate and maintained alternative.
@@ -144,7 +144,7 @@ CVE Checking
 ------------
 
 ``cve-check-tool`` has been functionally replaced by a new
-``cve-update-db`` recipe and functionality built into the :ref:`cve-check <ref-classes-cve-check>`
+``cve-update-db`` recipe and functionality built into the :ref:`ref-classes-cve-check`
 class. The result uses NVD JSON data feeds rather than the deprecated
 XML feeds that ``cve-check-tool`` was using, supports CVSSv3 scoring,
 and makes other improvements.
@@ -287,7 +287,7 @@ The following miscellaneous changes have occurred.
    :term:`NATIVELSBSTRING` to use all lowercase
    characters even if it does not contain a version number. This change
    is necessary only if you are not using
-   :ref:`uninative <ref-classes-uninative>` and :term:`SANITY_TESTED_DISTROS`.
+   :ref:`ref-classes-uninative` and :term:`SANITY_TESTED_DISTROS`.
 
 -  In the ``base-files`` recipe, writing the hostname into
    ``/etc/hosts`` and ``/etc/hostname`` is now done within the main

documentation/migration-guides/migration-3.1.rst

@@ -127,7 +127,7 @@ renamed to ``features_check``; the ``distro_features_check`` class still
 exists but generates a warning and redirects to the new class. In
 preparation for a future removal of the old class it is recommended that
 you update recipes currently inheriting ``distro_features_check`` to
-inherit :ref:`features_check <ref-classes-features_check>` instead.
+inherit :ref:`ref-classes-features_check` instead.
 
 .. _migration-3.1-removed-classes:
 
@@ -240,10 +240,10 @@ Warnings will now be shown at :ref:`ref-tasks-package_qa` time in the following
 circumstances:
 
 -  A recipe installs ``.desktop`` files containing ``MimeType`` keys but
-   does not inherit the new :ref:`mime-xdg <ref-classes-mime-xdg>` class
+   does not inherit the new :ref:`ref-classes-mime-xdg` class
 
 -  A recipe installs ``.xml`` files into ``${datadir}/mime/packages``
-   but does not inherit the :ref:`mime <ref-classes-mime>` class
+   but does not inherit the :ref:`ref-classes-mime` class
 
 .. _migration-3.1-x86-live-wic:
 

documentation/migration-guides/migration-3.2.rst

@@ -177,13 +177,23 @@ errors:
 
 In addition, the following new checks were added and default to triggering an error:
 
-- :ref:`shebang-size <qa-check-shebang-size>`: Check for shebang (#!) lines longer than 128 characters, which can give an error at runtime depending on the operating system.
+- :ref:`shebang-size <qa-check-shebang-size>`: Check for shebang (#!) lines
+  longer than 128 characters, which can give an error at runtime depending on
+  the operating system.
 
-- :ref:`unhandled-features-check <qa-check-unhandled-features-check>`: Check if any of the variables supported by the :ref:`features_check <ref-classes-features_check>` class is set while not inheriting the class itself.
+- :ref:`unhandled-features-check <qa-check-unhandled-features-check>`: Check
+  if any of the variables supported by the :ref:`ref-classes-features_check`
+  class is set while not inheriting the class itself.
 
-- :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`: Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its packages, and does not inherit the :ref:`update-alternatives <ref-classes-update-alternatives>` class.
+- :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`:
+  Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its
+  packages, and does not inherit the :ref:`ref-classes-update-alternatives`
+  class.
 
-- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable --- remove any instances of these in your recipes if the warning is displayed.
+- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B`
+  will now trigger a warning so that they can be removed and path comparisons
+  can be more reliable --- remove any instances of these in your recipes if the
+  warning is displayed.
 
 
 .. _migration-3.2-src-uri-file-globbing:
@@ -209,9 +219,18 @@ files into a subdirectory and reference that instead.
 deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
 ----------------------------------------------------------
 
-:ref:`ref-tasks-deploy` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
+:ref:`ref-tasks-deploy` as implemented in the :ref:`ref-classes-deploy` class
+now cleans up ${:term:`DEPLOYDIR`} before running, just as
+:ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces
+the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from
+previous runs, possibly even with different config, in case of incremental
+builds.
 
-Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with :ref:`ref-tasks-deploy` are unlikely to be affected by this unless they add ``prefuncs`` to :ref:`ref-tasks-deploy` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
+Most recipes and classes that inherit the :ref:`ref-classes-deploy` class or
+interact with :ref:`ref-tasks-deploy` are unlikely to be affected by this
+unless they add ``prefuncs`` to :ref:`ref-tasks-deploy` *which also* put files
+into ``${DEPLOYDIR}`` --- these should be refactored to use
+``do_deploy_prepend`` instead.
 
 
 .. _migration-3.2-nativesdk-sdk-provides-dummy:
@@ -219,7 +238,7 @@ Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` cla
 Custom SDK / SDK-style recipes need to include ``nativesdk-sdk-provides-dummy``
 -------------------------------------------------------------------------------
 
-All :ref:`nativesdk <ref-classes-nativesdk>` packages require ``/bin/sh`` due
+All :ref:`ref-classes-nativesdk` packages require ``/bin/sh`` due
 to their postinstall scriptlets, thus this package has to be dummy-provided
 within the SDK and ``nativesdk-sdk-provides-dummy`` now does this. If you have
 a custom SDK recipe (or your own SDK-style recipe similar to e.g.

documentation/migration-guides/migration-3.3.rst

@@ -63,13 +63,13 @@ need to update those.
 New ``python3targetconfig`` class
 ---------------------------------
 
-A new :ref:`python3targetconfig <ref-classes-python3targetconfig>` class has
+A new :ref:`ref-classes-python3targetconfig` class has
 been created for situations where you would previously have inherited the
-:ref:`python3native <ref-classes-python3native>` class but need access to
+:ref:`ref-classes-python3native` class but need access to
 target configuration data (such as correct installation directories). Recipes
 where this situation applies should be changed to inherit
-:ref:`python3targetconfig <ref-classes-python3targetconfig>` instead of
-:ref:`python3native <ref-classes-python3native>`. This also adds a dependency
+:ref:`ref-classes-python3targetconfig` instead of
+:ref:`ref-classes-python3native`. This also adds a dependency
 on target ``python3``, so it should only be used where appropriate in order to
 avoid unnecessarily lengthening builds.
 
@@ -99,11 +99,10 @@ variable so that recipes can specify it explicitly, for example::
    S = "${WORKDIR}/git"
    DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule"
 
-Recipes that inherit from ``distutils3`` (or
-:ref:`setuptools3 <ref-classes-setuptools3>` which itself inherits
-``distutils3``) that also set :term:`S` to point to a Python module within a
-subdirectory in the aforementioned manner should be changed to set
-``DISTUTILS_SETUP_PATH`` instead.
+Recipes that inherit from ``distutils3`` (or :ref:`ref-classes-setuptools3`
+which itself inherits ``distutils3``) that also set :term:`S` to point to a
+Python module within a subdirectory in the aforementioned manner should be
+changed to set ``DISTUTILS_SETUP_PATH`` instead.
 
 
 .. _migration-3.3-bitbake:

documentation/migration-guides/migration-3.4.rst

@@ -126,7 +126,7 @@ Removed classes
 - ``image-mklibs``: not actively tested and upstream mklibs still
   requires Python 2
 - ``meta``: no longer useful. Recipes that need to skip installing
-  packages should inherit :ref:`nopackages <ref-classes-nopackages>` instead.
+  packages should inherit :ref:`ref-classes-nopackages` instead.
 
 Prelinking disabled by default
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -259,7 +259,7 @@ Miscellaneous
   instead.
 
 - The obsolete ``oe_machinstall`` function previously provided in the
-  :ref:`utils <ref-classes-utils>` class has been removed. For
+  :ref:`ref-classes-utils` class has been removed. For
   machine-specific installation it is recommended that you use the
   built-in override support in the fetcher or overrides in general
   instead.

documentation/migration-guides/migration-4.0.rst

@@ -119,7 +119,7 @@ License changes
 - The ``AVAILABLE_LICENSES`` variable has been removed. This variable was a performance
   liability and is highly dependent on which layers are added to the configuration,
   which can cause signature issues for users. In addition the ``available_licenses()``
-  function has been removed from the :ref:`license <ref-classes-license>` class as
+  function has been removed from the :ref:`ref-classes-license` class as
   it is no longer needed.
   
 Removed recipes
@@ -143,15 +143,14 @@ Python changes
   
 - The Python package build process is now based on `wheels <https://pythonwheels.com/>`__.
   Here are the new Python packaging classes that should be used:
-  :ref:`python_flit_core <ref-classes-python_flit_core>`,
-  :ref:`python_setuptools_build_meta <ref-classes-python_setuptools_build_meta>`
-  and :ref:`python_poetry_core <ref-classes-python_poetry_core>`.  
+  :ref:`ref-classes-python_flit_core`, :ref:`ref-classes-python_setuptools_build_meta`
+  and :ref:`ref-classes-python_poetry_core`.
 
-- The :ref:`setuptools3 <ref-classes-setuptools3>` class :ref:`ref-tasks-install` task now
+- The :ref:`ref-classes-setuptools3` class :ref:`ref-tasks-install` task now
   installs the ``wheel`` binary archive. In current versions of ``setuptools`` the
   legacy ``setup.py install`` method is deprecated. If the ``setup.py`` cannot be used
   with wheels, for example it creates files outside of the Python module or standard
-  entry points, then :ref:`setuptools3_legacy <ref-classes-setuptools3_legacy>` should
+  entry points, then :ref:`ref-classes-setuptools3_legacy` should
   be used instead.
 
 Prelink removed
@@ -173,7 +172,7 @@ Reproducible as standard
 
 Reproducibility is now considered as standard functionality, thus the 
 ``reproducible`` class has been removed and its previous contents merged into the
-:ref:`base <ref-classes-base>` class. If you have references in your configuration to
+:ref:`ref-classes-base` class. If you have references in your configuration to
 ``reproducible`` in :term:`INHERIT`, :term:`USER_CLASSES` etc. then they should be
 removed.
 
@@ -215,15 +214,15 @@ Miscellaneous changes
 ~~~~~~~~~~~~~~~~~~~~~
   
 - ``blacklist.bbclass`` is removed and the functionality moved to the
-  :ref:`base <ref-classes-base>` class with a more descriptive
+  :ref:`ref-classes-base` class with a more descriptive
   ``varflag`` variable named :term:`SKIP_RECIPE` which will use the `bb.parse.SkipRecipe()`
   function. The usage remains the same, for example::
 
      SKIP_RECIPE[my-recipe] = "Reason for skipping recipe"
 
-- :ref:`allarch <ref-classes-allarch>` packagegroups can no longer depend on packages
+- :ref:`ref-classes-allarch` packagegroups can no longer depend on packages
   which use :term:`PKG` renaming such as :ref:`ref-classes-debian`. Such packagegroups
-  recipes should be changed to avoid inheriting :ref:`allarch <ref-classes-allarch>`.
+  recipes should be changed to avoid inheriting :ref:`ref-classes-allarch`.
 
 - The ``lnr`` script has been removed. ``lnr`` implemented the same behaviour as `ln --relative --symbolic`,
   since at the time of creation `--relative` was only available in coreutils 8.16
@@ -232,7 +231,7 @@ Miscellaneous changes
   any calls to ``lnr`` in your recipes or classes, they should be replaced with
   `ln --relative --symbolic` or `ln -rs` if you prefer the short version.
 
-- The ``package_qa_handle_error()`` function formerly in the :ref:`insane <ref-classes-insane>`
+- The ``package_qa_handle_error()`` function formerly in the :ref:`ref-classes-insane`
   class has been moved and renamed - if you have any references in your own custom
   classes they should be changed to ``oe.qa.handle_error()``.
 

documentation/migration-guides/migration-4.1.rst

@@ -92,7 +92,7 @@ now cause an error::
 
    INHERIT += "testimage"
 
-Since :ref:`testimage <ref-classes-testimage>` is a class intended solely to
+Since :ref:`ref-classes-testimage` is a class intended solely to
 affect image recipes, this would be correctly specified as::
 
    IMAGE_CLASSES += "testimage"
@@ -154,16 +154,16 @@ Miscellaneous changes
   you can set :term:`WATCHDOG_TIMEOUT` to the desired timeout in seconds. Note
   that the same :term:`WATCHDOG_TIMEOUT` variable also specifies the timeout used
   for the ``watchdog`` tool (if that is being built).
-- The :ref:`image-buildinfo <ref-classes-image-buildinfo>` class now writes to
+- The :ref:`ref-classes-image-buildinfo` class now writes to
   ``${sysconfdir}/buildinfo`` instead of ``${sysconfdir}/build`` by default (i.e.
   the default value of :term:`IMAGE_BUILDINFO_FILE` has been changed). If you have
   code that reads this from images at build or runtime you will need to update it
   or specify your own value for :term:`IMAGE_BUILDINFO_FILE`.
-- In the :ref:`archiver <ref-classes-archiver>` class, the default
+- In the :ref:`ref-classes-archiver` class, the default
   ``ARCHIVER_OUTDIR`` value no longer includes the :term:`MACHINE` value in order
   to avoid the archive task running multiple times in a multiconfig setup. If you
   have custom code that does something with the files archived by the
-  :ref:`archiver <ref-classes-archiver>` class then you may need to adjust it to
+  :ref:`ref-classes-archiver` class then you may need to adjust it to
   the new structure.
 - If you are not using `systemd` then udev is now configured to use labels
   (``LABEL`` or ``PARTLABEL``) to set the mount point for the device. For example::
@@ -194,7 +194,7 @@ Miscellaneous changes
   :term:`PACKAGECONFIG`. If you are customising this file you will need to
   update your customisations.
 - With the introduction of picobuild in
-  :ref:`python_pep517 <ref-classes-python_pep517>`, The ``PEP517_BUILD_API``
+  :ref:`ref-classes-python_pep517`, The ``PEP517_BUILD_API``
   variable is no longer supported. If you have any references to this variable
   you should remove them.
 

documentation/migration-guides/migration-general.rst

@@ -76,24 +76,24 @@ any new Yocto Project release.
 
 - *Checking Image / SDK Changes*:
 
-   The :ref:`buildhistory <ref-classes-buildhistory>` class can be used
+   The :ref:`ref-classes-buildhistory` class can be used
    if you wish to check the impact of changes to images / SDKs across
    the migration (e.g. added/removed packages, added/removed files, size
    changes etc.). To do this, follow these steps:
 
-   #. Enable :ref:`buildhistory <ref-classes-buildhistory>` before the migration
+   #. Enable :ref:`ref-classes-buildhistory` before the migration
 
    #. Run a pre-migration build
 
-   #. Capture the :ref:`buildhistory <ref-classes-buildhistory>` output (as
+   #. Capture the :ref:`ref-classes-buildhistory` output (as
       specified by :term:`BUILDHISTORY_DIR`) and ensure it is preserved for
       subsequent builds. How you would do this depends on how you are running
       your builds - if you are doing this all on one workstation in the same
       :term:`Build Directory` you may not need to do anything other than not
-      deleting the :ref:`buildhistory <ref-classes-buildhistory>` output
+      deleting the :ref:`ref-classes-buildhistory` output
       directory. For builds in a pipeline it may be more complicated.
 
-   #. Set a tag in the :ref:`buildhistory <ref-classes-buildhistory>` output (which is a git repository) before
+   #. Set a tag in the :ref:`ref-classes-buildhistory` output (which is a git repository) before
       migration, to make the commit from the pre-migration build easy to find
       as you may end up running multiple builds during the migration.
 
@@ -102,7 +102,7 @@ any new Yocto Project release.
    #. Run a build
 
    #. Check the output changes between the previously set tag and HEAD in the
-      :ref:`buildhistory <ref-classes-buildhistory>` output using ``git diff`` or ``buildhistory-diff``.
+      :ref:`ref-classes-buildhistory` output using ``git diff`` or ``buildhistory-diff``.
 
-   For more information on using :ref:`buildhistory <ref-classes-buildhistory>`, see
+   For more information on using :ref:`ref-classes-buildhistory`, see
    :ref:`dev-manual/build-quality:maintaining build output quality`.

documentation/migration-guides/release-notes-3.4.rst

@@ -9,7 +9,7 @@ New Features / Enhancements in 3.4
 -  Linux kernel 5.14, glibc 2.34 and ~280 other recipe upgrades
 -  Switched override character to ':' (replacing '_') for more robust parsing and improved performance --- see the above migration guide for help
 -  Rust integrated into core, providing rust support for cross-compilation and SDK
--  New :ref:`create-spdx <ref-classes-create-spdx>` class for creating SPDX SBoM documents
+-  New :ref:`ref-classes-create-spdx` class for creating SPDX SBoM documents
 -  New recipes: cargo, core-image-ptest-all, core-image-ptest-fast, core-image-weston-sdk, erofs-utils, gcompat, gi-docgen, libmicrohttpd, libseccomp, libstd-rs, perlcross, python3-markdown, python3-pyyaml, python3-smartypants, python3-typogrify, rust, rust-cross, rust-cross-canadian, rust-hello-world, rust-llvm, rust-tools-cross-canadian, rustfmt, xwayland
 -  Several optimisations to reduce unnecessary task dependencies for faster builds
 -  seccomp integrated into core, with additional enabling for gnutls, systemd, qemu
@@ -71,7 +71,7 @@ New Features / Enhancements in 3.4
 
    -  Enable :ref:`ref-tasks-populate_sdk` with multilibs
    -  New ``SDKPATHINSTALL`` variable decouples default install path from
-      built in path to avoid rebuilding :ref:`nativesdk <ref-classes-nativesdk>`
+      built in path to avoid rebuilding :ref:`ref-classes-nativesdk`
       components on e.g. :term:`DISTRO_VERSION` changes
    -  eSDK: Error if trying to generate an eSDK from a multiconfig
    -  eSDK: introduce :term:`TOOLCHAIN_HOST_TASK_ESDK` to be used in place of :term:`TOOLCHAIN_HOST_TASK` to add components to the host part of the eSDK

documentation/migration-guides/release-notes-4.0.rst

@@ -13,7 +13,7 @@ New Features / Enhancements in 4.0
 - Reproducibility: this release fixes the reproducibility issues with
   ``rust-llvm`` and ``golang``. Recipes in OpenEmbedded-Core are now fully
   reproducible. Functionality previously in the optional "reproducible"
-  class has been merged into the :ref:`base <ref-classes-base>` class.
+  class has been merged into the :ref:`ref-classes-base` class.
 
 - Network access is now disabled by default for tasks other than where it is expected to ensure build integrity (where host kernel supports it)
 
@@ -31,8 +31,7 @@ New Features / Enhancements in 4.0
 - The Python package build process is now based on `wheels <https://pythonwheels.com/>`__
   in line with the upstream direction.
 
-- New :ref:`overlayfs <ref-classes-overlayfs>` and
-  :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` classes and
+- New :ref:`ref-classes-overlayfs` and :ref:`ref-classes-overlayfs-etc` classes and
   ``overlayroot`` support in the :term:`Initramfs` framework to make it easier to
   overlay read-only filesystems (for example) with
   :wikipedia:`OverlayFS <OverlayFS>`.
@@ -218,7 +217,7 @@ New Features / Enhancements in 4.0
    - Ensure addition of patch-fuzz retriggers do_qa_patch
    - Added a sanity check for allarch packagegroups
 
-- :ref:`create-spdx <ref-classes-create-spdx>` class improvements:
+- :ref:`ref-classes-create-spdx` class improvements:
 
    - Get SPDX-License-Identifier from source files
    - Generate manifest also for SDKs
@@ -238,9 +237,9 @@ New Features / Enhancements in 4.0
    
 - SDK-related enhancements:
 
-   - Extended recipes to :ref:`nativesdk <ref-classes-nativesdk>`: ``cargo``,
+   - Extended recipes to :ref:`ref-classes-nativesdk`: ``cargo``,
      ``librsvg``, ``libstd-rs``, ``libva``, ``python3-docutil``, ``python3-packaging``
-   - Enabled :ref:`nativesdk <ref-classes-nativesdk>` recipes to find a correct version
+   - Enabled :ref:`ref-classes-nativesdk` recipes to find a correct version
      of the rust cross compiler
    - Support creating per-toolchain cmake file in SDK
 

documentation/migration-guides/release-notes-4.1.rst

@@ -30,7 +30,7 @@ New Features / Enhancements in 4.1
   - Support for building rust for the target
   - Significant SDK toolchain build optimisation
   - Support for building native components in the SDK
-  - Support ``crate://`` fetcher with :ref:`externalsrc <ref-classes-externalsrc>`
+  - Support ``crate://`` fetcher with :ref:`ref-classes-externalsrc`
 
 - New core recipes:
 
@@ -52,7 +52,7 @@ New Features / Enhancements in 4.1
   - Added support for Ignored CVEs
   - Enable recursive CVE checking also for ``do_populate_sdk``
   - New :term:`CVE_CHECK_SHOW_WARNINGS` variable to disable unpatched CVE warning messages
-  - The :ref:`pypi <ref-classes-pypi>` class now defaults :term:`CVE_PRODUCT` from :term:`PYPI_PACKAGE`
+  - The :ref:`ref-classes-pypi` class now defaults :term:`CVE_PRODUCT` from :term:`PYPI_PACKAGE`
   - Added current kernel CVEs to ignore list since we stay as close to the kernel stable releases as we can
   - Optimisations to avoid dependencies on fetching
 
@@ -60,9 +60,9 @@ New Features / Enhancements in 4.1
 - Dependency of -dev package on main package is now an :term:`RRECOMMENDS` and can be easily set via new :term:`DEV_PKG_DEPENDENCY` variable
 
 - Support for CPU, I/O and memory pressure regulation in BitBake
-- Pressure data gathering in :ref:`buildstats <ref-classes-buildstats>` and rendering in ``pybootchartgui``
+- Pressure data gathering in :ref:`ref-classes-buildstats` and rendering in ``pybootchartgui``
 
-- New Picobuild system for lightweight Python PEP-517 build support in the :ref:`python_pep517 <ref-classes-python_pep517>` class
+- New Picobuild system for lightweight Python PEP-517 build support in the :ref:`ref-classes-python_pep517` class
 
 - Many classes are now split into global and recipe contexts for better
   validation. For more information, see
@@ -99,10 +99,10 @@ New Features / Enhancements in 4.1
 -  SDK-related enhancements:
 
    - :ref:`Support for using the regular build system as an SDK <sdk-manual/extensible:Setting up the Extensible SDK environment directly in a Yocto build>`
-   - :ref:`image-buildinfo <ref-classes-image-buildinfo>` class now also writes build information to SDKs
+   - :ref:`ref-classes-image-buildinfo` class now also writes build information to SDKs
    - New :term:`SDK_TOOLCHAIN_LANGS` variable to control support of rust / go in SDK
-   - rust-llvm: enabled :ref:`nativesdk <ref-classes-nativesdk>` variant
-   - python3-pluggy: enabled for :ref:`native <ref-classes-native>` / :ref:`nativesdk <ref-classes-nativesdk>`
+   - rust-llvm: enabled :ref:`ref-classes-nativesdk` variant
+   - python3-pluggy: enabled for :ref:`ref-classes-native` / :ref:`ref-classes-nativesdk`
 
 -  QEMU/runqemu enhancements:
 
@@ -115,11 +115,11 @@ New Features / Enhancements in 4.1
    - New variable :term:`UBOOT_MKIMAGE_KERNEL_TYPE`
    - New variable :term:`FIT_PAD_ALG` to control FIT image padding algorithm
    - New :term:`KERNEL_DEPLOY_DEPEND` variable to allow disabling image dependency on deploying the kernel
-   - :ref:`image_types <ref-classes-image_types>`: isolate the write of UBI
+   - :ref:`ref-classes-image_types`: isolate the write of UBI
      configuration to a ``write_ubi_config`` function that can be easily overridden
 
 - openssh: add support for config snippet includes to ssh and sshd
-- :ref:`create-spdx <ref-classes-create-spdx>`: Add :term:`SPDX_PRETTY` option
+- :ref:`ref-classes-create-spdx`: Add :term:`SPDX_PRETTY` option
 - wpa-supplicant: build static library if not disabled via :term:`DISABLE_STATIC`
 - wpa-supplicant: package dynamic modules
 - openssl: extract legacy provider module to a separate package
@@ -132,11 +132,11 @@ New Features / Enhancements in 4.1
 - systemd: systemd-systemctl: Support instance conf files during enable
 - weston.init: enable ``xwayland`` in weston.ini if ``x11`` is in :term:`DISTRO_FEATURES`
 - New ``npm_registry`` Python module to enable caching with nodejs 16+
-- :ref:`npm <ref-classes-npm>`: replaced ``npm pack`` call with ``tar czf`` for nodejs 16+ compatibility and improved ``do_configure`` performance
-- Enabled :ref:`bin_package <ref-classes-bin-package>` class to work properly in the native case
+- :ref:`ref-classes-npm`: replaced ``npm pack`` call with ``tar czf`` for nodejs 16+ compatibility and improved ``do_configure`` performance
+- Enabled :ref:`ref-classes-bin-package` class to work properly in the native case
 - Enabled :ref:`buildpaths <qa-check-buildpaths>` QA check as a warning by default
-- New :term:`OVERLAYFS_ETC_EXPOSE_LOWER` to provide read-only access to the original ``/etc`` content with :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`
-- New :term:`OVERLAYFS_QA_SKIP` variable to allow skipping check on :ref:`overlayfs <ref-classes-overlayfs>` mounts
+- New :term:`OVERLAYFS_ETC_EXPOSE_LOWER` to provide read-only access to the original ``/etc`` content with :ref:`ref-classes-overlayfs-etc`
+- New :term:`OVERLAYFS_QA_SKIP` variable to allow skipping check on :ref:`ref-classes-overlayfs` mounts
 - New :term:`PACKAGECONFIG` options for individual recipes:
 
    - apr: xsi-strerror
@@ -176,7 +176,7 @@ New Features / Enhancements in 4.1
 - The Python ``zoneinfo`` module is now split out to its own ``python3-zoneinfo`` package.
 - busybox: added devmem 128-bit support
 - vim: split xxd out into its own package
-- New :ref:`github-releases <ref-classes-github-releases>` class to consolidate version checks for github-based packages
+- New :ref:`ref-classes-github-releases` class to consolidate version checks for github-based packages
 - ``devtool reset`` now preserves ``workspace/sources`` source trees in ``workspace/attic/sources/`` instead of leaving them in-place
 - scripts/patchreview: Add commit to stored json data
 - scripts/patchreview: Make json output human parsable
@@ -204,7 +204,7 @@ Known Issues in 4.1
   :yocto_bugs:`bug 14626 </show_bug.cgi?id=14626>`, which also details the fix.
 
 - The change to :ref:`migration-4.1-classes-split` inadvertently moved the
-  :ref:`externalsrc <ref-classes-externalsrc>` class to ``meta/classes-recipe``,
+  :ref:`ref-classes-externalsrc` class to ``meta/classes-recipe``,
   when it is not recipe-specific and can also be used in a global context.  The
   class will be moved back to ``meta/classes`` in the next point release.  Filed
   as :yocto_bugs:`bug 14940 </show_bug.cgi?id=14940>`.

documentation/overview-manual/concepts.rst

@@ -107,8 +107,7 @@ Classes
 -------
 
 Class files (``.bbclass``) contain information that is useful to share
-between recipes files. An example is the
-:ref:`autotools <ref-classes-autotools>` class,
+between recipes files. An example is the :ref:`ref-classes-autotools` class,
 which contains common settings for any application that is built with
 the :wikipedia:`GNU Autotools <GNU_Autotools>`.
 The ":ref:`ref-manual/classes:Classes`" chapter in the Yocto Project
@@ -561,11 +560,11 @@ reside somewhere local to a project --- perhaps a directory into which the
 user checks in items (e.g. a local directory containing a development
 source tree used by the group).
 
-The canonical method through which to include a local project is to use
-the :ref:`externalsrc <ref-classes-externalsrc>`
-class to include that local project. You use either the ``local.conf``
-or a recipe's append file to override or set the recipe to point to the
-local directory on your disk to pull in the whole source tree.
+The canonical method through which to include a local project is to use the
+:ref:`ref-classes-externalsrc` class to include that local project. You use
+either the ``local.conf`` or a recipe's append file to override or set the
+recipe to point to the local directory on your disk to pull in the whole
+source tree.
 
 Source Control Managers (Optional)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -628,8 +627,7 @@ types, and you specify which classes to enable through the
 :term:`PACKAGE_CLASSES`
 variable. Before placing the packages into package feeds, the build
 process validates them with generated output quality assurance checks
-through the :ref:`insane <ref-classes-insane>`
-class.
+through the :ref:`ref-classes-insane` class.
 
 The package feed area resides in the :term:`Build Directory`. The directory the
 build system uses to temporarily store packages is determined by a
@@ -840,14 +838,12 @@ This step in the build process consists of the following tasks:
    are specific to configurations for the source code being built by the
    recipe.
 
-   If you are using the
-   :ref:`autotools <ref-classes-autotools>` class,
+   If you are using the :ref:`ref-classes-autotools` class,
    you can add additional configuration options by using the
    :term:`EXTRA_OECONF` or
    :term:`PACKAGECONFIG_CONFARGS`
    variables. For information on how this variable works within that
-   class, see the
-   :ref:`autotools <ref-classes-autotools>` class
+   class, see the :ref:`ref-classes-autotools` class
    :yocto_git:`here </poky/tree/meta/classes-recipe/autotools.bbclass>`.
 
 -  *do_compile*: Once a configuration task has been satisfied,
@@ -920,7 +916,7 @@ the analysis and package splitting process use several areas:
 -  :term:`STAGING_DIR_TARGET`:
    The path for the sysroot used when a component that is built to
    execute on a system and it generates code for yet another machine
-   (e.g. :ref:`cross-canadian <ref-classes-cross-canadian>` recipes).
+   (e.g. :ref:`ref-classes-cross-canadian` recipes).
 
 The :term:`FILES` variable defines the
 files that go into each package in
@@ -1006,13 +1002,11 @@ is read-only.
 The final stages of the :ref:`ref-tasks-rootfs` task handle post processing. Post
 processing includes creation of a manifest file and optimizations.
 
-The manifest file (``.manifest``) resides in the same directory as the
-root filesystem image. This file lists out, line-by-line, the installed
-packages. The manifest file is useful for the
-:ref:`testimage <ref-classes-testimage>` class,
+The manifest file (``.manifest``) resides in the same directory as the root
+filesystem image. This file lists out, line-by-line, the installed packages.
+The manifest file is useful for the :ref:`ref-classes-testimage` class,
 for example, to determine whether or not to run specific tests. See the
-:term:`IMAGE_MANIFEST`
-variable for additional information.
+:term:`IMAGE_MANIFEST` variable for additional information.
 
 Optimizing processes that are run across the image include ``mklibs``
 and any other post-processing commands as defined by the
@@ -1751,12 +1745,11 @@ half the problem of supporting a shared state. The other half of the
 problem is being able to use checksum information during the build and
 being able to reuse or rebuild specific components.
 
-The :ref:`sstate <ref-classes-sstate>` class is a
-relatively generic implementation of how to "capture" a snapshot of a
-given task. The idea is that the build process does not care about the
-source of a task's output. Output could be freshly built or it could be
-downloaded and unpacked from somewhere. In other words, the build
-process does not need to worry about its origin.
+The :ref:`ref-classes-sstate` class is a relatively generic implementation of
+how to "capture" a snapshot of a given task. The idea is that the build process
+does not care about the source of a task's output. Output could be freshly
+built or it could be downloaded and unpacked from somewhere. In other words,
+the build process does not need to worry about its origin.
 
 Two types of output exist. One type is just about creating a directory
 in :term:`WORKDIR`. A good example is
@@ -1767,10 +1760,9 @@ type of output occurs when a set of data is merged into a shared
 directory tree such as the sysroot.
 
 The Yocto Project team has tried to keep the details of the
-implementation hidden in the :ref:`sstate <ref-classes-sstate>` class. From a user's perspective,
+implementation hidden in the :ref:`ref-classes-sstate` class. From a user's perspective,
 adding shared state wrapping to a task is as simple as this
-:ref:`ref-tasks-deploy` example taken
-from the :ref:`deploy <ref-classes-deploy>` class::
+:ref:`ref-tasks-deploy` example taken from the :ref:`ref-classes-deploy` class::
 
    DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
    SSTATETASKS += "do_deploy"
@@ -1786,11 +1778,9 @@ from the :ref:`deploy <ref-classes-deploy>` class::
 
 The following list explains the previous example:
 
--  Adding ``do_deploy`` to ``SSTATETASKS`` adds some required
-   sstate-related processing, which is implemented in the
-   :ref:`sstate <ref-classes-sstate>` class, to
-   before and after the
-   :ref:`ref-tasks-deploy` task.
+-  Adding ``do_deploy`` to ``SSTATETASKS`` adds some required sstate-related
+   processing, which is implemented in the :ref:`ref-classes-sstate` class, to
+   before and after the :ref:`ref-tasks-deploy` task.
 
 -  The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that
    :ref:`ref-tasks-deploy` places its output in ``${DEPLOYDIR}`` when run normally

documentation/ref-manual/features.rst

@@ -358,7 +358,7 @@ Here are the image features available for all images:
    a given image.
 
 Some image features are available only when you inherit the
-:ref:`core-image <ref-classes-core-image>` class. The current list of
+:ref:`ref-classes-core-image` class. The current list of
 these valid features is as follows:
 
 -  *hwcodecs:* Installs hardware acceleration codecs.

documentation/ref-manual/qa-checks.rst

@@ -580,7 +580,7 @@ Errors and Warnings
 
    The specified package contains mime type files (``.xml`` files in
    ``${datadir}/mime/packages``) and yet does not inherit the
-   :ref:`mime <ref-classes-mime>` class which will ensure that these get
+   :ref:`ref-classes-mime` class which will ensure that these get
    properly installed. Either add ``inherit mime`` to the recipe or remove the
    files at the :ref:`ref-tasks-install` step if they are not needed.
 
@@ -590,7 +590,7 @@ Errors and Warnings
 - ``package contains desktop file with key 'MimeType' but does not inhert mime-xdg: <packagename> path '<file>' [mime-xdg]``
 
     The specified package contains a .desktop file with a 'MimeType' key
-    present, but does not inherit the :ref:`mime-xdg <ref-classes-mime-xdg>`
+    present, but does not inherit the :ref:`ref-classes-mime-xdg`
     class that is required in order for that to be activated. Either add
     ``inherit mime`` to the recipe or remove the files at the
     :ref:`ref-tasks-install` step if they are not needed.
@@ -621,9 +621,9 @@ Errors and Warnings
 - ``<recipename>: recipe doesn't inherit features_check [unhandled-features-check]``
 
     This check ensures that if one of the variables that the
-    :ref:`features_check <ref-classes-features_check>` class supports (e.g.
+    :ref:`ref-classes-features_check` class supports (e.g.
     :term:`REQUIRED_DISTRO_FEATURES`) is used, then the recipe
-    inherits :ref:`features_check <ref-classes-features_check>` in order for
+    inherits :ref:`ref-classes-features_check` in order for
     the requirement to actually work. If you are seeing this message, either
     add ``inherit features_check`` to your recipe or remove the reference to
     the variable if it is not needed.
@@ -634,7 +634,7 @@ Errors and Warnings
 - ``<recipename>: recipe defines ALTERNATIVE:<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]``
 
     This check ensures that if a recipe sets the :term:`ALTERNATIVE` variable that the
-    recipe also inherits :ref:`update-alternatives <ref-classes-update-alternatives>` such
+    recipe also inherits :ref:`ref-classes-update-alternatives` such
     that the alternative will be correctly set up. If you are seeing this message, either
     add ``inherit update-alternatives`` to your recipe or remove the reference to the variable
     if it is not needed.
@@ -655,7 +655,7 @@ Errors and Warnings
 - ``<packagename> contains perllocal.pod (<files>), should not be installed [perllocalpod]``
 
     ``perllocal.pod`` is an index file of locally installed modules and so shouldn't be
-    installed by any distribution packages. The :ref:`cpan <ref-classes-cpan>` class
+    installed by any distribution packages. The :ref:`ref-classes-cpan` class
     already sets ``NO_PERLLOCAL`` to stop this file being generated by most Perl recipes,
     but if a recipe is using ``MakeMaker`` directly then they might not be doing this
     correctly. This check ensures that perllocal.pod is not in any package in order to

documentation/ref-manual/structure.rst

@@ -233,7 +233,7 @@ is available via the :term:`TOPDIR` variable.
 -----------------------
 
 The OpenEmbedded build system creates this directory when you enable
-build history via the :ref:`buildhistory <ref-classes-buildhistory>` class file. The directory
+build history via the :ref:`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/build-quality:maintaining build output quality`"
@@ -375,7 +375,7 @@ remove the ``build/sstate-cache`` directory.
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This directory stores the build statistics as generated by the
-:ref:`buildstats <ref-classes-buildstats>` class.
+:ref:`ref-classes-buildstats` class.
 
 .. _structure-build-tmp-cache:
 

documentation/ref-manual/tasks.rst

@@ -78,9 +78,9 @@ task runs with the current working directory set to
 ``${``\ :term:`B`\ ``}``.
 
 Recipes implementing this task should inherit the
-:ref:`deploy <ref-classes-deploy>` class and should write the output
+:ref:`ref-classes-deploy` class and should write the output
 to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be
-confused with ``${DEPLOY_DIR}``. The :ref:`deploy <ref-classes-deploy>` class sets up
+confused with ``${DEPLOY_DIR}``. The :ref:`ref-classes-deploy` class sets up
 :ref:`ref-tasks-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 @@ Adding :ref:`ref-tasks-deploy` after other tasks works the same way.
 .. note::
 
    You do not need to add ``before do_build`` to the ``addtask`` command
-   (though it is harmless), because the :ref:`base <ref-classes-base>` class contains the following::
+   (though it is harmless), because the :ref:`ref-classes-base` class contains the following::
 
            do_build[recrdeptask] += "do_deploy"
 
@@ -225,7 +225,7 @@ section in the Yocto Project Overview and Concepts Manual.
 -----------------
 
 Runs QA checks on packaged files. For more information on these checks,
-see the :ref:`insane <ref-classes-insane>` class.
+see the :ref:`ref-classes-insane` class.
 
 .. _ref-tasks-package_write_deb:
 
@@ -406,7 +406,7 @@ Installs the files into the individual recipe specific sysroots (i.e.
 ``recipe-sysroot`` and ``recipe-sysroot-native`` under
 ``${``\ :term:`WORKDIR`\ ``}`` based upon the
 dependencies specified by :term:`DEPENDS`). See the
-":ref:`staging <ref-classes-staging>`" class for more information.
+":ref:`ref-classes-staging`" class for more information.
 
 .. _ref-tasks-rm_work:
 

documentation/sdk-manual/appendix-customizing.rst

@@ -49,8 +49,7 @@ build system applies them against ``local.conf`` and ``auto.conf``:
    :term:`ESDK_CLASS_INHERIT_DISABLE` to disable these classes is the typical
    method to disable classes that are problematic or unnecessary in the SDK
    context. The default value disables the
-   :ref:`buildhistory <ref-classes-buildhistory>` and
-   :ref:`icecc <ref-classes-icecc>` classes.
+   :ref:`ref-classes-buildhistory` and :ref:`ref-classes-icecc` classes.
 
 Additionally, the contents of ``conf/sdk-extra.conf``, when present, are
 appended to the end of ``conf/local.conf`` within the produced SDK,

documentation/sdk-manual/extensible.rst

@@ -1079,9 +1079,8 @@ does not include complete instructions for building the software.
 Instead, common functionality is encapsulated in classes inherited with
 the ``inherit`` directive. This technique leaves the recipe to describe
 just the things that are specific to the software being built. There is
-a :ref:`base <ref-classes-base>` class that
-is implicitly inherited by all recipes and provides the functionality
-that most recipes typically need.
+a :ref:`ref-classes-base` class that is implicitly inherited by all recipes
+and provides the functionality that most recipes typically need.
 
 The remainder of this section presents information useful when working
 with recipes.

documentation/test-manual/intro.rst

@@ -100,12 +100,11 @@ the following types of tests:
    different configurations, such as different init systems. The
    Autobuilder tests literally hundreds of configurations and targets.
 
-   -  *Sanity Checks During the Build Process:* Tests initiated through
-      the :ref:`insane <ref-classes-insane>`
-      class. These checks ensure the output of the builds are correct.
-      For example, does the ELF architecture in the generated binaries
-      match the target system? ARM binaries would not work in a MIPS
-      system!
+   -  *Sanity Checks During the Build Process:* Tests initiated through the
+      :ref:`ref-classes-insane` class. These checks ensure the output of the
+      builds are correct. For example, does the ELF architecture in the
+      generated binaries match the target system? ARM binaries would not work
+      in a MIPS system!
 
 -  *Build Performance Testing:* Tests whether or not commonly used steps
    during builds work efficiently and avoid regressions. Tests to time
@@ -121,7 +120,8 @@ the following types of tests:
 
       $ bitbake image -c testsdkext
 
-   The tests utilize the :ref:`testsdkext <ref-classes-testsdk>` class and the ``do_testsdkext`` task.
+   The tests utilize the :ref:`ref-classes-testsdk` class and the
+   ``do_testsdkext`` task.
 
 -  *Feature Testing:* Various scenario-based tests are run through the
    :ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distributions
@@ -131,7 +131,7 @@ the following types of tests:
 
       $ bitbake image -c testimage
 
-   The tests utilize the :ref:`testimage <ref-classes-testimage>`
+   The tests utilize the :ref:`ref-classes-testimage`
    class and the :ref:`ref-tasks-testimage` task.
 
 -  *Layer Testing:* The Autobuilder has the possibility to test whether
@@ -151,7 +151,7 @@ the following types of tests:
 
       $ bitbake image -c testsdk
 
-   The tests utilize the :ref:`testsdk <ref-classes-testsdk>` class and
+   The tests utilize the :ref:`ref-classes-testsdk` class and
    the ``do_testsdk`` task.
 
 -  *Unit Testing:* Unit tests on various components of the system run

documentation/test-manual/understand-autobuilder.rst

@@ -206,7 +206,7 @@ are general setup steps that are run once and include:
 
 #. Set up any :term:`buildtools` tarball if configured.
 
-#. Call "buildhistory-init" if :ref:`buildhistory <ref-classes-buildhistory>` is configured.
+#. Call "buildhistory-init" if :ref:`ref-classes-buildhistory` is configured.
 
 For each step that is configured in ``config.json``, it will perform the
 following: