From 8b1909aa6f7a51a878dc3d4a9223403ad3e164a9 Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Thu, 5 Jan 2023 08:34:26 +0100 Subject: 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 `. 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 Suggested-by: Quentin Schulz Signed-off-by: Richard Purdie --- documentation/dev-manual/build-quality.rst | 12 ++- documentation/dev-manual/building.rst | 15 ++-- documentation/dev-manual/debugging.rst | 8 +- documentation/dev-manual/disk-space.rst | 3 +- documentation/dev-manual/error-reporting-tool.rst | 6 +- documentation/dev-manual/gobject-introspection.rst | 4 +- documentation/dev-manual/licenses.rst | 19 +++-- documentation/dev-manual/new-recipe.rst | 85 ++++++++++------------ documentation/dev-manual/packages.rst | 16 ++-- documentation/dev-manual/quilt.rst | 4 +- documentation/dev-manual/read-only-rootfs.rst | 2 +- documentation/dev-manual/runtime-testing.rst | 4 +- documentation/dev-manual/sbom.rst | 4 +- documentation/dev-manual/securing-images.rst | 8 +- documentation/dev-manual/speeding-up-build.rst | 3 +- documentation/dev-manual/upgrading-recipes.rst | 3 +- documentation/dev-manual/vulnerabilities.rst | 10 +-- documentation/dev-manual/wic.rst | 3 +- 18 files changed, 91 insertions(+), 118 deletions(-) (limited to 'documentation/dev-manual') 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 ` -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 ` - or :ref:`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 ` 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 ` 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 ` - 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 ` 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 ` + 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 ` 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 ` 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 ` 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 ` 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 ` -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 ` - 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 ` 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 ` class, you need to -decide how you choose to provide source. The source :ref:`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 ` 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 ` and :ref:`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 ` 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 ` 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 `" 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 ` and - :ref:`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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` class -and to be sure that you are using default locations for build artifacts. -In most cases, the :ref:`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 ` 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 ` 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 `":: +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 ` wiki page. .. note:: - A recipe is "ptest-enabled" if it inherits the - :ref:`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 ` *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 ` 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 ` 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 ` enabled, the + recipe or have :ref:`ref-classes-rm-work` enabled, the :ref:`devtool 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` - 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 ` 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 ` + - 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 ` 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 ` 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 ` 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 ` + 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 -- cgit v1.2.3-54-g00ecf