ref-manual: Updated the do_fetch closer look for checksum behavior.

Fixes [YOCTO #5521]

I created a brief note in the do_fetch subsection of the
"Taking a Closer Look" section to deal with how the build
system uses checksums during do_fetch to re-execute stuff
if a file:// listed in the SRC_URI has had its contents
modified.

(From yocto-docs rev: 7b857635f2663af7c1d5e8aa87239472a5b47919)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 13 insertions, 2 deletions

diff --git a/documentation/ref-manual/closer-look.xml b/documentation/ref-manual/closer-look.xml
index 7546215ae6..f0ed967228 100644
--- a/documentation/ref-manual/closer-look.xml
+++ b/documentation/ref-manual/closer-look.xml
@@ -713,8 +713,19 @@
                 <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
                 and
                 <link linkend='ref-tasks-unpack'><filename>do_unpack</filename></link>
-                tasks fetch the source files
-                and unpack them into the work directory.
+                tasks fetch the source files and unpack them into the work
+                directory.
+                <note>
+                    For every local file (e.g. <filename>file://</filename>)
+                    that is part of a recipe's
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                    statement, the OpenEmbedded build system takes a checksum
+                    of the file for the recipe and inserts the checksum into
+                    the signature for the <filename>do_fetch</filename>.
+                    If any local file has been modified, the
+                    <filename>do_fetch</filename> task and all tasks that
+                    depend on it are re-executed.
+                </note>
                 By default, everything is accomplished in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
                 which has a defined structure.