diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml
index 8b6e0b442f..571424b99f 100644
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml
+++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml
@@ -7,7 +7,8 @@
The primary purpose for running BitBake is to produce some kind
of output such as a single installable package, a kernel, a software
- development kit, or even a full, board-specific bootable Linux image.
+ development kit, or even a full, board-specific bootable Linux image,
+ complete with bootloader, kernel, and root filesystem.
Of course, you can execute the bitbake
command with options that cause it to execute single tasks,
compile single recipe files, capture or clear data, or simply
@@ -45,6 +46,11 @@
build host with hyper-threading will most likely show eight processors,
which is the value you would then assign to that variable.
+
+
+ A possibly simpler solution is that some Linux distributions
+ (e.g. Debian and Ubuntu) provide the ncpus command.
+
@@ -464,6 +470,29 @@
PREFERRED_VERSION_a = "1.1"
+
+
+
+ It is common for a recipe to provide two versions -- a stable,
+ numbered (and preferred) version, and a version that is
+ automatically checked out from a source code repository that
+ is considered more "bleeding edge" but can be selected only
+ explicitly.
+
+
+
+ For example, in the OpenEmbedded codebase, there is a standard,
+ versioned recipe file for BusyBox,
+ busybox_1.22.1.bb,
+ but there is also a Git-based version,
+ busybox_git.bb, which explicitly contains the line
+
+ DEFAULT_PREFERENCE = "-1"
+
+ to ensure that the numbered, stable version is always preferred
+ unless the developer selects otherwise.
+
+