docs: dev-manual-common-tasks: remove paragraph about race when missing DEPENDS

Missing DEPENDS were an issue before rocko (2.4) because of a shared global
sysroot. Since then, every recipe has its own sysroot, it is not possible
to build successfully a recipe without all DEPENDS. Therefore, races in
tasks possibly triggered by missing DEPENDS are a thing of the past.

This paragraph is misleading and can be safely removed.

(From yocto-docs rev: 9aec42794846a4bca37b49a9f920fa2887974ddf)

Signed-off-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 7 insertions, 16 deletions

diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index 943180296c..7cb25c02cd 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -1611,25 +1611,16 @@ Within a recipe, you specify build-time dependencies using the
 :term:`DEPENDS` variable. Although
 nuances exist, items specified in ``DEPENDS`` should be names of other
 recipes. It is important that you specify all build-time dependencies
-explicitly. If you do not, due to the parallel nature of BitBake's
-execution, you can end up with a race condition where the dependency is
-present for one task of a recipe (e.g.
-:ref:`ref-tasks-configure`) and
-then gone when the next task runs (e.g.
-:ref:`ref-tasks-compile`).
+explicitly.
 
 Another consideration is that configure scripts might automatically
 check for optional dependencies and enable corresponding functionality
-if those dependencies are found. This behavior means that to ensure
-deterministic results and thus avoid more race conditions, you need to
-either explicitly specify these dependencies as well, or tell the
-configure script explicitly to disable the functionality. If you wish to
-make a recipe that is more generally useful (e.g. publish the recipe in
-a layer for others to use), instead of hard-disabling the functionality,
-you can use the
-:term:`PACKAGECONFIG` variable
-to allow functionality and the corresponding dependencies to be enabled
-and disabled easily by other users of the recipe.
+if those dependencies are found. If you wish to make a recipe that is
+more generally useful (e.g. publish the recipe in a layer for others to
+use), instead of hard-disabling the functionality, you can use the
+:term:`PACKAGECONFIG` variable to allow functionality and the
+corresponding dependencies to be enabled and disabled easily by other
+users of the recipe.
 
 Similar to build-time dependencies, you specify runtime dependencies
 through a variable -