15 files changed, 86 insertions, 91 deletions

diff --git a/documentation/dev-manual/building.rst b/documentation/dev-manual/building.rst
index 807c665f68..32c7aa5da0 100644
--- a/documentation/dev-manual/building.rst
+++ b/documentation/dev-manual/building.rst
@@ -48,7 +48,7 @@ The following figure and list overviews the build process:
    :width: 100%
 
 #. *Set up Your Host Development System to Support Development Using the
-   Yocto Project*: See the ":doc:`start`" section for options on how to get a
+   Yocto Project*: See the ":doc:`/dev-manual/start`" section for options on how to get a
    build host ready to use the Yocto Project.
 
 #. *Initialize the Build Environment:* Initialize the build environment
@@ -113,7 +113,7 @@ The following figure and list overviews the build process:
 Building Images for Multiple Targets Using Multiple Configurations
 ==================================================================
 
-See the :doc:`multiconfig` section of the Yocto Project Development Tasks
+See the :doc:`/dev-manual/multiconfig` section of the Yocto Project Development Tasks
 Manual.
 
 Building an Initial RAM Filesystem (Initramfs) Image
@@ -591,7 +591,7 @@ If build speed and package feed maintenance are considerations, you
 should consider the points in this section that can help you optimize
 your tunings to best consider build times and package feed maintenance.
 
--  *Share the :term:`Build Directory`:* If at all possible, share the
+-  *Share the* :term:`Build Directory` *:* If at all possible, share the
    :term:`TMPDIR` across builds. The Yocto Project supports switching between
    different :term:`MACHINE` values in the same :term:`TMPDIR`. This practice
    is well supported and regularly used by developers when building for
@@ -813,7 +813,7 @@ directory:
 
 #. *Using Local Files Only:* Inside your ``local.conf`` file, add the
    :term:`SOURCE_MIRROR_URL` variable, inherit the
-   :ref:`ref-classes-own-mirrors` class, and use the
+   :ref:`ref-classes-own-mirrors` class, and add the
    :term:`BB_NO_NETWORK` variable to your ``local.conf``::
 
       SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/"
diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst
index 8552b26aea..6c45ccf652 100644
--- a/documentation/dev-manual/debugging.rst
+++ b/documentation/dev-manual/debugging.rst
@@ -890,7 +890,7 @@ The build should work without issue.
 As with all solved problems, if they originated upstream, you need to
 submit the fix for the recipe in OE-Core and upstream so that the
 problem is taken care of at its source. See the
-":doc:`../contributor-guide/submit-changes`" section for more information.
+":doc:`/contributor-guide/submit-changes`" section for more information.
 
 Debugging With the GNU Project Debugger (GDB) Remotely
 ======================================================
@@ -1261,7 +1261,7 @@ Here are some other tips that you might find useful:
    :yocto_bugs:`Bugzilla <>`. For information on
    how to submit a bug against the Yocto Project, see the Yocto Project
    Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
-   and the ":doc:`../contributor-guide/report-defect`" section.
+   and the ":doc:`/contributor-guide/report-defect`" section.
 
    .. note::
 
diff --git a/documentation/dev-manual/disk-space.rst b/documentation/dev-manual/disk-space.rst
index efca82601d..ba3afa5a2c 100644
--- a/documentation/dev-manual/disk-space.rst
+++ b/documentation/dev-manual/disk-space.rst
@@ -52,7 +52,7 @@ such as BSD based NAS::
    sstate-cache-management.py --remove-duplicated --cache-dir=sstate-cache
 
 This command will ask you to confirm the deletions it identifies.
-Run ``sstate-cache-management.sh`` for more details about this script.
+Run ``sstate-cache-management.py`` for more details about this script.
 
 .. note::
 
diff --git a/documentation/dev-manual/efficiently-fetching-sources.rst b/documentation/dev-manual/efficiently-fetching-sources.rst
index a15f0a92ce..a3366226c0 100644
--- a/documentation/dev-manual/efficiently-fetching-sources.rst
+++ b/documentation/dev-manual/efficiently-fetching-sources.rst
@@ -6,7 +6,7 @@ Efficiently Fetching Source Files During a Build
 The OpenEmbedded build system works with source files located through
 the :term:`SRC_URI` variable. When
 you build something using BitBake, a big part of the operation is
-locating and downloading all the source tarballs. For images,
+locating and downloading all of the source code. For images,
 downloading all the source for various packages can take a significant
 amount of time.
 
@@ -18,7 +18,7 @@ Setting up Effective Mirrors
 ============================
 
 A good deal that goes into a Yocto Project build is simply downloading
-all of the source tarballs. Maybe you have been working with another
+source code. Maybe you have been working with another
 build system for which you have built up a
 sizable directory of source tarballs. Or, perhaps someone else has such
 a directory for which you have read access. If so, you can save time by
diff --git a/documentation/dev-manual/init-manager.rst b/documentation/dev-manual/init-manager.rst
index ddce82b81f..d0fdfdf773 100644
--- a/documentation/dev-manual/init-manager.rst
+++ b/documentation/dev-manual/init-manager.rst
@@ -44,7 +44,7 @@ therefore increasing the total system boot time. systemd also substantially
 increases system size because of its multiple components and the extra
 dependencies it pulls.
 
-On the contrary, BusyBox init is the simplest and the lightest solution and
+By contrast, BusyBox init is the simplest and the lightest solution and
 also comes with BusyBox mdev as device manager, a lighter replacement to
 :wikipedia:`udev <Udev>`, which SysVinit and systemd both use.
 
diff --git a/documentation/dev-manual/layers.rst b/documentation/dev-manual/layers.rst
index c649e2bd60..67482bf544 100644
--- a/documentation/dev-manual/layers.rst
+++ b/documentation/dev-manual/layers.rst
@@ -80,7 +80,7 @@ Follow these general steps to create your layer without using tools:
       BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
       BBFILE_PRIORITY_yoctobsp = "5"
       LAYERVERSION_yoctobsp = "4"
-      LAYERSERIES_COMPAT_yoctobsp = "dunfell"
+      LAYERSERIES_COMPAT_yoctobsp = "walnascar"
 
    Here is an explanation of the layer configuration file:
 
@@ -306,7 +306,7 @@ The Yocto Project Compatibility Program consists of a layer application
 process that requests permission to use the Yocto Project Compatibility
 Logo for your layer and application. The process consists of two parts:
 
-#. Successfully passing a script (``yocto-check-layer``) that when run
+#. Successfully passing a script (``yocto-check-layer``) that, when run
    against your layer, tests it against constraints based on experiences
    of how layers have worked in the real world and where pitfalls have
    been found. Getting a "PASS" result from the script is required for
@@ -478,7 +478,7 @@ name. To handle these errors, the best practice is to rename the ``.bbappend``
 to match the original recipe version. This also gives you the opportunity to see
 if the ``.bbappend`` is still relevant for the new version of the recipe.
 
-Another method it to use the character ``%`` in the ``.bbappend`` filename. For
+Another method is to use the character ``%`` in the ``.bbappend`` filename. For
 example, to append information to every ``6.*`` minor versions of the recipe
 ``someapp``, the ``someapp_6.%.bbappend`` file can be created. This way, an
 error will only be triggered if the ``someapp`` recipe has a major version
@@ -504,10 +504,9 @@ the "meta" layer at ``meta/recipes-bsp/formfactor``::
    SECTION = "base"
    LICENSE = "MIT"
    LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-   PR = "r45"
 
    SRC_URI = "file://config file://machconfig"
-   S = "${WORKDIR}"
+   S = "${UNPACKDIR}"
 
    PACKAGE_ARCH = "${MACHINE_ARCH}"
    INHIBIT_DEFAULT_DEPS = "1"
@@ -582,11 +581,10 @@ Directory`.  Here is the main ``xserver-xf86-config`` recipe, which is named
    SECTION = "x11/base"
    LICENSE = "MIT"
    LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-   PR = "r33"
 
    SRC_URI = "file://xorg.conf"
 
-   S = "${WORKDIR}"
+   S = "${UNPACKDIR}"
 
    CONFFILES:${PN} = "${sysconfdir}/X11/xorg.conf"
 
@@ -594,9 +592,9 @@ Directory`.  Here is the main ``xserver-xf86-config`` recipe, which is named
    ALLOW_EMPTY:${PN} = "1"
 
    do_install () {
-        if test -s ${WORKDIR}/xorg.conf; then
+        if test -s ${UNPACKDIR}/xorg.conf; then
                 install -d ${D}/${sysconfdir}/X11
-                install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
+                install -m 0644 ${UNPACKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
         fi
    }
 
@@ -614,8 +612,8 @@ file is in the layer at ``recipes-graphics/xorg-xserver``::
        PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
        if [ "${PITFT}" = "1" ]; then
            install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
-           install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
-           install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
+           install -m 0644 ${UNPACKDIR}/xorg.conf.d/98-pitft.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
+           install -m 0644 ${UNPACKDIR}/xorg.conf.d/99-calibration.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
        fi
    }
 
diff --git a/documentation/dev-manual/libraries.rst b/documentation/dev-manual/libraries.rst
index 521dbb9a7c..a8c38128ea 100644
--- a/documentation/dev-manual/libraries.rst
+++ b/documentation/dev-manual/libraries.rst
@@ -37,40 +37,10 @@ library files.
    Some previously released versions of the Yocto Project defined the
    static library files through ``${PN}-dev``.
 
-Here is the part of the BitBake configuration file, where you can see
+Here is a small part of the BitBake configuration file, where you can see
 how the static library files are defined::
 
-   PACKAGE_BEFORE_PN ?= ""
    PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
-   PACKAGES_DYNAMIC = "^${PN}-locale-.*"
-   FILES = ""
-
-   FILES:${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
-               ${sysconfdir} ${sharedstatedir} ${localstatedir} \
-               ${base_bindir}/* ${base_sbindir}/* \
-               ${base_libdir}/*${SOLIBS} \
-               ${base_prefix}/lib/udev ${prefix}/lib/udev \
-               ${base_libdir}/udev ${libdir}/udev \
-               ${datadir}/${BPN} ${libdir}/${BPN}/* \
-               ${datadir}/pixmaps ${datadir}/applications \
-               ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
-               ${libdir}/bonobo/servers"
-
-   FILES:${PN}-bin = "${bindir}/* ${sbindir}/*"
-
-   FILES:${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
-               ${datadir}/gnome/help"
-   SECTION:${PN}-doc = "doc"
-
-   FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
-   FILES:${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
-                   ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
-                   ${datadir}/aclocal ${base_libdir}/*.o \
-                   ${libdir}/${BPN}/*.la ${base_libdir}/*.la \
-                   ${libdir}/cmake ${datadir}/cmake"
-   SECTION:${PN}-dev = "devel"
-   ALLOW_EMPTY:${PN}-dev = "1"
-   RDEPENDS:${PN}-dev = "${PN} (= ${EXTENDPKGV})"
 
    FILES:${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
    SECTION:${PN}-staticdev = "devel"
diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst
index bffff3675f..7d6636eeff 100644
--- a/documentation/dev-manual/licenses.rst
+++ b/documentation/dev-manual/licenses.rst
@@ -55,11 +55,11 @@ Consider this next example::
 
    LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
                                        md5=bb14ed3c4cda583abc85401304b5cd4e"
-   LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
+   LIC_FILES_CHKSUM = "file://${UNPACKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
 
 The first line locates a file in ``${S}/src/ls.c`` and isolates lines
 five through 16 as license text. The second line refers to a file in
-:term:`WORKDIR`.
+:term:`UNPACKDIR`.
 
 Note that :term:`LIC_FILES_CHKSUM` variable is mandatory for all recipes,
 unless the :term:`LICENSE` variable is set to "CLOSED".
diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst
index 9792bd4c1f..832aa300e1 100644
--- a/documentation/dev-manual/new-recipe.rst
+++ b/documentation/dev-manual/new-recipe.rst
@@ -188,13 +188,14 @@ the recipe.
    Use lower-cased characters and do not include the reserved suffixes
    ``-native``, ``-cross``, ``-initial``, or ``-dev`` casually (i.e. do not use
    them as part of your recipe name unless the string applies). Here are some
-   examples:
+   examples (which includes the use of the string "git" as a special case of a
+   version identifier):
 
    .. code-block:: none
 
-      cups_1.7.0.bb
-      gawk_4.0.2.bb
-      irssi_0.8.16-rc1.bb
+      cups_2.4.12.bb
+      gawk_5.3.2.bb
+      psplash_git.bb
 
 Running a Build on the Recipe
 =============================
@@ -276,11 +277,11 @@ upgrading the recipe to a future version is as simple as renaming the
 recipe to match the new version.
 
 Here is a simple example from the
-``meta/recipes-devtools/strace/strace_5.5.bb`` recipe where the source
-comes from a single tarball. Notice the use of the
+:oe_git:`strace recipe </openembedded-core/tree/meta/recipes-devtools/strace>`
+where the source comes from a single tarball. Notice the use of the
 :term:`PV` variable::
 
-   SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
+   SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/strace-${PV}.tar.xz \
 
 Files mentioned in :term:`SRC_URI` whose names end in a typical archive
 extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so
@@ -292,7 +293,7 @@ another example that specifies these types of files, see the
 Another way of specifying source is from an SCM. For Git repositories,
 you must specify :term:`SRCREV` and you should specify :term:`PV` to include
 a ``+`` sign in its definition. Here is an example from the recipe
-:oe_git:`meta/recipes-sato/l3afpad/l3afpad_git.bb </openembedded-core/tree/meta/recipes-sato/l3afpad/l3afpad_git.bb>`::
+:oe_git:`l3afpad_git.bb </openembedded-core/tree/meta/recipes-sato/l3afpad/l3afpad_git.bb>`::
 
    SRC_URI = "git://github.com/stevenhoneyman/l3afpad.git;branch=master;protocol=https"
 
@@ -347,8 +348,8 @@ paste them into your recipe and then run the build again to continue.
    continuing with the build.
 
 This final example is a bit more complicated and is from the
-``meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb`` recipe. The
-example's :term:`SRC_URI` statement identifies multiple files as the source
+:oe_git:`rxvt-unicode </openembedded-core/tree/meta/recipes-sato/rxvt-unicode>`
+recipe. The example's :term:`SRC_URI` statement identifies multiple files as the source
 files for the recipe: a tarball, a patch file, a desktop file, and an icon::
 
    SRC_URI = "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \
@@ -706,7 +707,7 @@ hierarchy to locations that would mirror their locations on the target
 device. The installation process copies files from the
 ``${``\ :term:`S`\ ``}``,
 ``${``\ :term:`B`\ ``}``, and
-``${``\ :term:`WORKDIR`\ ``}``
+``${``\ :term:`UNPACKDIR`\ ``}``
 directories to the ``${``\ :term:`D`\ ``}``
 directory to create the structure as it should appear on the target
 system.
@@ -1145,7 +1146,7 @@ Building an application from a single file that is stored locally (e.g. under
 ``files``) requires a recipe that has the file listed in the :term:`SRC_URI`
 variable. Additionally, you need to manually write the :ref:`ref-tasks-compile`
 and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the
-directory containing the source code, which is set to :term:`WORKDIR` in this
+directory containing the source code, which is set to :term:`UNPACKDIR` in this
 case --- the directory BitBake uses for the build::
 
    SUMMARY = "Simple helloworld application"
@@ -1155,7 +1156,7 @@ case --- the directory BitBake uses for the build::
 
    SRC_URI = "file://helloworld.c"
 
-   S = "${WORKDIR}"
+   S = "${UNPACKDIR}"
 
    do_compile() {
        ${CC} ${LDFLAGS} helloworld.c -o helloworld
@@ -1211,8 +1212,6 @@ In the following example, ``lz4`` is a makefile-based package::
               "
    UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>.*)"
 
-   S = "${WORKDIR}/git"
-
    CVE_STATUS[CVE-2014-4715] = "fixed-version: Fixed in r118, which is larger than the current version"
 
    EXTRA_OEMAKE = "PREFIX=${prefix} CC='${CC}' CFLAGS='${CFLAGS}' DESTDIR=${D} LIBDIR=${libdir} INCLUDEDIR=${includedir} BUILD_STATIC=no"
@@ -1271,8 +1270,6 @@ is a simple example of an application without dependencies::
    SRC_URI = "git://gitlab.com/ipcalc/ipcalc.git;protocol=https;branch=master"
    SRCREV = "4c4261a47f355946ee74013d4f5d0494487cc2d6"
 
-   S = "${WORKDIR}/git"
-
    inherit meson
 
 Applications with dependencies are likely to inherit the
@@ -1397,11 +1394,31 @@ doing the following:
    where you have installed them and whether those files are in
    different locations than the defaults.
 
+As a basic example of a :ref:`ref-classes-bin-package`-style recipe, consider
+this snippet from the
+:oe_git:`wireless-regdb </openembedded-core/tree/meta/recipes-kernel/wireless-regdb>`
+recipe file, which fetches a single tarball of binary content and manually
+installs with no need for any configuration or compilation::
+
+   SRC_URI = "https://www.kernel.org/pub/software/network/${BPN}/${BP}.tar.xz"
+   SRC_URI[sha256sum] = "57f8e7721cf5a880c13ae0c202edbb21092a060d45f9e9c59bcd2a8272bfa456"
+
+   inherit bin_package allarch
+
+   do_install() {
+       install -d -m0755 ${D}${nonarch_libdir}/crda
+       install -d -m0755 ${D}${sysconfdir}/wireless-regdb/pubkeys
+       install -m 0644 regulatory.bin ${D}${nonarch_libdir}/crda/regulatory.bin
+       install -m 0644 wens.key.pub.pem ${D}${sysconfdir}/wireless-regdb/pubkeys/wens.key.pub.pem
+       install -m 0644 -D regulatory.db ${D}${nonarch_base_libdir}/firmware/regulatory.db
+       install -m 0644 regulatory.db.p7s ${D}${nonarch_base_libdir}/firmware/regulatory.db.p7s
+   }
+
 Following Recipe Style Guidelines
 =================================
 
 When writing recipes, it is good to conform to existing style guidelines.
-See the ":doc:`../contributor-guide/recipe-style-guide`" in the Yocto Project
+See the ":doc:`/contributor-guide/recipe-style-guide`" in the Yocto Project
 and OpenEmbedded Contributor Guide for reference.
 
 It is common for existing recipes to deviate a bit from this style.
@@ -1428,7 +1445,7 @@ chapter of the BitBake User Manual.
    The following example shows some of the ways you can use variables in
    recipes::
 
-      S = "${WORKDIR}/postfix-${PV}"
+      S = "${UNPACKDIR}/postfix-${PV}"
       CFLAGS += "-DNO_ASM"
       CFLAGS:append = " --enable-important-feature"
 
diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst
index 8845bf2fab..8bd48c8e8f 100644
--- a/documentation/dev-manual/packages.rst
+++ b/documentation/dev-manual/packages.rst
@@ -1024,7 +1024,7 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe::
        npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
        "
 
-   S = "${WORKDIR}/npm"
+   S = "${UNPACKDIR}/npm"
 
    inherit npm
 
diff --git a/documentation/dev-manual/prebuilt-libraries.rst b/documentation/dev-manual/prebuilt-libraries.rst
index a05f39ca1e..59621ca16d 100644
--- a/documentation/dev-manual/prebuilt-libraries.rst
+++ b/documentation/dev-manual/prebuilt-libraries.rst
@@ -97,7 +97,7 @@ The complete recipe would look like this::
    # we use a local link.
    SRC_URI = "file://libft4222-linux-${PV}.tgz"
 
-   S = "${WORKDIR}"
+   S = "${UNPACKDIR}"
 
    ARCH_DIR:x86-64 = "build-x86_64"
    ARCH_DIR:i586 = "build-i386"
@@ -170,7 +170,7 @@ as follows::
 The modifications cause the ``.so`` file to be the real library
 and unset :term:`FILES_SOLIBSDEV` so that no libraries get packaged into
 ``${PN}-dev``. The changes are required because unless :term:`PACKAGES` is changed,
-``${PN}-dev`` collects files before `${PN}`. ``${PN}-dev`` must not collect any of
+``${PN}-dev`` collects files before ``${PN}``. ``${PN}-dev`` must not collect any of
 the files you want in ``${PN}``.
 
 Finally, loadable modules, essentially unversioned libraries that are linked
@@ -204,6 +204,6 @@ versioned library example. The "magic" is setting the :term:`SOLIBS` and
 
    do_install () {
            install -d ${D}${libdir}
-           install -m 0755 ${WORKDIR}/libfoo.so ${D}${libdir}
+           install -m 0755 ${UNPACKDIR}/libfoo.so ${D}${libdir}
    }
 
diff --git a/documentation/dev-manual/sbom.rst b/documentation/dev-manual/sbom.rst
index e6806ce929..ca0fc8b9d6 100644
--- a/documentation/dev-manual/sbom.rst
+++ b/documentation/dev-manual/sbom.rst
@@ -60,6 +60,9 @@ more information in the output :term:`SPDX` data:
 -  Add a description of the source files used to generate host tools and target
    packages (:term:`SPDX_INCLUDE_SOURCES`)
 
+-  Add a description of the **compiled** source files used to generate host tools
+   and target packages (:term:`SPDX_INCLUDE_COMPILED_SOURCES`)
+
 -  Add archives of these source files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
 
 Though the toplevel :term:`SPDX` output is available in
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst
index 73548132a3..44bd2de137 100644
--- a/documentation/dev-manual/start.rst
+++ b/documentation/dev-manual/start.rst
@@ -109,7 +109,7 @@ particular working environment and set of practices.
 
     -  Keep your cross-development toolchains updated. You can do this
        through provisioning either as new toolchain downloads or as
-       updates through a package update mechanism using ``opkg`` to
+       updates through a package update mechanism to
        provide updates to an existing toolchain. The exact mechanics of
        how and when to do this depend on local policy.
 
@@ -159,7 +159,7 @@ particular working environment and set of practices.
        are made.
 
     -  Allows triggering of automated image booting and testing under
-       the QuickEMUlator (QEMU).
+       the Quick EMUlator (QEMU).
 
     -  Supports incremental build testing and from-scratch builds.
 
@@ -234,7 +234,7 @@ particular working environment and set of practices.
     -  The Yocto Project community encourages you to send patches to the
        project to fix bugs or add features. If you do submit patches,
        follow the project commit guidelines for writing good commit
-       messages. See the ":doc:`../contributor-guide/submit-changes`"
+       messages. See the ":doc:`/contributor-guide/submit-changes`"
        section in the Yocto Project and OpenEmbedded Contributor Guide.
 
     -  Send changes to the core sooner than later as others are likely
@@ -310,7 +310,7 @@ Project Build Host:
 
    -  GNU make &MIN_MAKE_VERSION; or greater
 
-   If your build host does not meet any of these listed version
+   If your build host does not satisfy all of these listed version
    requirements, you can take steps to prepare the system so that you
    can still use the Yocto Project. See the
    ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
@@ -568,7 +568,7 @@ extension accordingly.
 Locating Yocto Project Source Files
 ===================================
 
-This section shows you how to locate, fetch and configure the source
+This section shows you how to locate, fetch, unpack, patch and configure the source
 files you'll need to work with the Yocto Project.
 
 .. note::
@@ -720,11 +720,11 @@ Follow these steps to create a local version of the upstream
       $ git branch
       * master
 
-   Your local repository of poky is identical to the
-   upstream poky repository at the time from which it was cloned. As you
+   Your local repository of poky is initially identical to the
+   upstream poky repository from which it was cloned. As you
    work with the local branch, you can periodically use the
-   ``git pull --rebase`` command to be sure you are up-to-date
-   with the upstream branch.
+   ``git pull`` command to be sure you stay up-to-date
+   with the upstream poky branch.
 
 Checking Out by Branch in Poky
 ------------------------------
diff --git a/documentation/dev-manual/temporary-source-code.rst b/documentation/dev-manual/temporary-source-code.rst
index 08bf68d982..9a7cd0f771 100644
--- a/documentation/dev-manual/temporary-source-code.rst
+++ b/documentation/dev-manual/temporary-source-code.rst
@@ -18,11 +18,10 @@ build packages is available in the :term:`Build Directory` as defined by the
 defined in the ``meta/conf/bitbake.conf`` configuration file in the
 :term:`Source Directory`::
 
-   S = "${WORKDIR}/${BP}"
+   S = "${UNPACKDIR}/${BP}"
 
 You should be aware that many recipes override the
-:term:`S` variable. For example, recipes that fetch their source from Git
-usually set :term:`S` to ``${WORKDIR}/git``.
+:term:`S` variable when the default isn't accurate.
 
 .. note::
 
@@ -31,8 +30,16 @@ usually set :term:`S` to ``${WORKDIR}/git``.
 
            BP = "${BPN}-${PV}"
 
+   This matches the location that the git fetcher unpacks to, and usually
+   matches unpacked content of release tarballs (e.g. they contain a single
+   directory which matches value of ${BP} exactly).
 
-The path to the work directory for the recipe
+The path to the unpack directory for the recipe
+(:term:`UNPACKDIR`) is defined as follows::
+
+   ${WORKDIR}/sources
+
+In turn, the path to the work directory for the recipe
 (:term:`WORKDIR`) is defined as
 follows::
 
diff --git a/documentation/dev-manual/vulnerabilities.rst b/documentation/dev-manual/vulnerabilities.rst
index d901ff975b..5331a63991 100644
--- a/documentation/dev-manual/vulnerabilities.rst
+++ b/documentation/dev-manual/vulnerabilities.rst
@@ -22,7 +22,7 @@ issues may be impacting Poky and OE-Core. It is up to the maintainers, users,
 contributors and anyone interested in the issues to investigate and possibly fix them by
 updating software components to newer versions or by applying patches to address them.
 It is recommended to work with Poky and OE-Core upstream maintainers and submit
-patches to fix them, see ":doc:`../contributor-guide/submit-changes`" for details.
+patches to fix them, see ":doc:`/contributor-guide/submit-changes`" for details.
 
 Vulnerability check at build time
 =================================