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>

18 files changed, 91 insertions, 118 deletions

diff --git a/documentation/dev-manual/build-quality.rst b/documentation/dev-manual/build-quality.rst
index 03eee12bef..713ea3a48e 100644
--- a/documentation/dev-manual/build-quality.rst
+++ b/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:
 
diff --git a/documentation/dev-manual/building.rst b/documentation/dev-manual/building.rst
index 3064974cc5..1f1642e846 100644
--- a/documentation/dev-manual/building.rst
+++ b/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
diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst
index 921022475f..9fb159eae6 100644
--- a/documentation/dev-manual/debugging.rst
+++ b/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.
 
diff --git a/documentation/dev-manual/disk-space.rst b/documentation/dev-manual/disk-space.rst
index 6fa48e1f4a..3a5d2b7297 100644
--- a/documentation/dev-manual/disk-space.rst
+++ b/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
diff --git a/documentation/dev-manual/error-reporting-tool.rst b/documentation/dev-manual/error-reporting-tool.rst
index 6854f1046a..84f3d9cd1e 100644
--- a/documentation/dev-manual/error-reporting-tool.rst
+++ b/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"
 
diff --git a/documentation/dev-manual/gobject-introspection.rst b/documentation/dev-manual/gobject-introspection.rst
index 28e51240c3..f7206e6fae 100644
--- a/documentation/dev-manual/gobject-introspection.rst
+++ b/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
diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst
index 0f8d759519..65914e5efe 100644
--- a/documentation/dev-manual/licenses.rst
+++ b/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
diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst
index 3adebf2746..4751f64b7e 100644
--- a/documentation/dev-manual/new-recipe.rst
+++ 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
diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst
index 2decdcb253..0c584c177a 100644
--- a/documentation/dev-manual/packages.rst
+++ b/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::
 
diff --git a/documentation/dev-manual/quilt.rst b/documentation/dev-manual/quilt.rst
index 24343e2fac..59240705ad 100644
--- a/documentation/dev-manual/quilt.rst
+++ b/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.
 
diff --git a/documentation/dev-manual/read-only-rootfs.rst b/documentation/dev-manual/read-only-rootfs.rst
index e29659c678..251178ed54 100644
--- a/documentation/dev-manual/read-only-rootfs.rst
+++ b/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
 =======================
diff --git a/documentation/dev-manual/runtime-testing.rst b/documentation/dev-manual/runtime-testing.rst
index 36ccf746ee..c5c5653bef 100644
--- a/documentation/dev-manual/runtime-testing.rst
+++ b/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"
 
diff --git a/documentation/dev-manual/sbom.rst b/documentation/dev-manual/sbom.rst
index d155b4775f..c67b7344d1 100644
--- a/documentation/dev-manual/sbom.rst
+++ b/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`),
diff --git a/documentation/dev-manual/securing-images.rst b/documentation/dev-manual/securing-images.rst
index f8dd572104..6a9223c19c 100644
--- a/documentation/dev-manual/securing-images.rst
+++ b/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::
 
diff --git a/documentation/dev-manual/speeding-up-build.rst b/documentation/dev-manual/speeding-up-build.rst
index 696b1bdf76..31b6f75ab0 100644
--- a/documentation/dev-manual/speeding-up-build.rst
+++ b/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
diff --git a/documentation/dev-manual/upgrading-recipes.rst b/documentation/dev-manual/upgrading-recipes.rst
index dd220cc6c8..13133fddcf 100644
--- a/documentation/dev-manual/upgrading-recipes.rst
+++ b/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::
 
diff --git a/documentation/dev-manual/vulnerabilities.rst b/documentation/dev-manual/vulnerabilities.rst
index f8dac5edc6..0ee3ec52c5 100644
--- a/documentation/dev-manual/vulnerabilities.rst
+++ b/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.
diff --git a/documentation/dev-manual/wic.rst b/documentation/dev-manual/wic.rst
index d698cec77c..a8d2f46955 100644
--- a/documentation/dev-manual/wic.rst
+++ b/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