documentation: Fixed links for "metadata" term.

Fixes [YOCTO #11630]

Moving the "Yocto Project Terms" section from the dev-manual
to the ref-manual broke the links to the "Metadata" term.
I fixed these.

(From yocto-docs rev: 190da4b4d44952d141db26ca72b5bc1a52d77023)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

18 files changed, 32 insertions, 31 deletions

diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 9226e5cdd4..40c2a7dd27 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -417,7 +417,7 @@
                     released with the BSP.
                     The information in the <filename>README.sources</filename>
                     file also helps you find the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
                     used to generate the images that ship with the BSP.
                     <note>
                         If the BSP's <filename>binary</filename> directory is
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index d73b663250..108ac78fe0 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -18,7 +18,8 @@
 
         <para>
             The OpenEmbedded build system supports organizing
-            <link linkend='metadata'>Metadata</link> into multiple layers.
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> into
+            multiple layers.
             Layers allow you to isolate different types of customizations from
             each other.
             You might find it tempting to keep everything in one layer when
@@ -6933,8 +6934,8 @@
         <para>
             When you build an image using the Yocto Project and
             do not alter any distribution
-            <link linkend='metadata'>Metadata</link>, you are creating a
-            Poky distribution.
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
+            you are creating a Poky distribution.
             If you wish to gain more control over package alternative
             selections, compile-time options, and other low-level
             configurations, you can create your own distribution.
@@ -11680,8 +11681,8 @@
        "
                 </literallayout>
                 Creating and providing an archive of the
-                <link linkend='metadata'>Metadata</link> layers
-                (recipes, configuration files, and so forth)
+                <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+                layers (recipes, configuration files, and so forth)
                 enables you to meet your
                 requirements to include the scripts to control compilation
                 as well as any modifications to the original source.
diff --git a/documentation/dev-manual/dev-manual-intro.xml b/documentation/dev-manual/dev-manual-intro.xml
index 020f9373e6..98d5d53758 100644
--- a/documentation/dev-manual/dev-manual-intro.xml
+++ b/documentation/dev-manual/dev-manual-intro.xml
@@ -36,7 +36,7 @@
         <note>
             By default, using the Yocto Project creates a Poky distribution.
             However, you can create your own distribution by providing key
-            <link linkend='metadata'>Metadata</link>.
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>.
             A good example is Angstrom, which has had a distribution
             based on the Yocto Project since its inception.
             Other examples include commercial distributions like
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 5a3e3ea107..b9fc265211 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -211,7 +211,7 @@
 
         <para>
             Keeping your
-            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
             and any software you are developing under the
             control of an SCM system that is compatible
             with the OpenEmbedded build system is advisable.
diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml
index 6b97c52ada..271c9fed0e 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -41,7 +41,7 @@
         <note>
             By default, using the Yocto Project creates a Poky distribution.
             However, you can create your own distribution by providing key
-            <link linkend='metadata'>Metadata</link>.
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>.
             See the "<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
             section for more information.
         </note>
diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml b/documentation/kernel-dev/kernel-dev-advanced.xml
index 5c08019655..22afc66587 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -11,7 +11,7 @@
     <para>
         In addition to supporting configuration fragments and patches, the
         Yocto Project kernel tools also support rich
-        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> that you can
+        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> that you can
         use to define complex policies and Board Support Package (BSP) support.
         The purpose of the Metadata and the tools that manage it, known as
         the kern-tools (<filename>kern-tools-native_git.bb</filename>), is
diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml
index 5af0f9a927..8c74a7081e 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -759,7 +759,7 @@
             working with your own sources.
             When you use your own sources, you will not be able to
             leverage the existing kernel
-            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> and
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> and
             stabilization work of the linux-yocto sources.
             However, you will be able to manage your own Metadata in the same
             format as the linux-yocto sources.
diff --git a/documentation/kernel-dev/kernel-dev-intro.xml b/documentation/kernel-dev/kernel-dev-intro.xml
index 263e50098f..83ca988acf 100644
--- a/documentation/kernel-dev/kernel-dev-intro.xml
+++ b/documentation/kernel-dev/kernel-dev-intro.xml
@@ -35,7 +35,7 @@
             Regardless of how you intend to make use of the Yocto Project,
             chances are you will work with the Linux kernel.
             This manual provides background information on the Yocto Linux kernel
-            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
             describes common tasks you can perform using the kernel tools,
             and shows you how to use the kernel Metadata needed to work with
             the kernel inside the Yocto Project.
diff --git a/documentation/ref-manual/closer-look.xml b/documentation/ref-manual/closer-look.xml
index e4a2a022a7..5046465fba 100644
--- a/documentation/ref-manual/closer-look.xml
+++ b/documentation/ref-manual/closer-look.xml
@@ -12,7 +12,7 @@
         high level.
         The remainder of this chapter expands on the fundamental input, output,
         process, and
-        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>) blocks
+        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>) blocks
         in the Yocto Project development environment.
     </para>
 
diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml
index 5c700bc5ea..b6b067b910 100644
--- a/documentation/ref-manual/migration.xml
+++ b/documentation/ref-manual/migration.xml
@@ -251,7 +251,7 @@
                 The following recipes have been removed.
                 For most of them, it is unlikely that you would have any
                 references to them in your own
-                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>.
+                <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>.
                 However, you should check your metadata against this list to be sure:
                 <itemizedlist>
                     <listitem><para><emphasis><filename>libx11-trim</filename></emphasis>:
diff --git a/documentation/ref-manual/ref-bitbake.xml b/documentation/ref-manual/ref-bitbake.xml
index 2f36e16eaf..9a9499115c 100644
--- a/documentation/ref-manual/ref-bitbake.xml
+++ b/documentation/ref-manual/ref-bitbake.xml
@@ -8,7 +8,7 @@
 
     <para>
         BitBake is a program written in Python that interprets the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> used by
+        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> used by
         the OpenEmbedded build system.
         At some point, developers wonder what actually happens when you enter:
         <literallayout class='monospaced'>
@@ -24,7 +24,7 @@
         BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships.
         As such, it has no real knowledge of what the tasks being executed actually do.
         BitBake just considers a list of tasks with dependencies and handles
-        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
         consisting of variables in a certain format that get passed to the tasks.
     </note>
 
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
index 472215c25a..1801faf501 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -16,7 +16,7 @@
 </para>
 
 <para>
-    Any <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> usually
+    Any <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> usually
     found in a recipe can also be placed in a class file.
     Class files are identified by the extension <filename>.bbclass</filename>
     and are usually placed in a <filename>classes/</filename> directory beneath
@@ -2419,7 +2419,7 @@ This check was removed for YP 2.3 release
         all dependencies previously built.
         The reason for this discrepancy is because the RPM package manager
         creates and processes more
-        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> than the
+        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> than the
         IPK package manager.
         Consequently, you might consider setting
         <filename>PACKAGE_CLASSES</filename> to "package_ipk" if you are
diff --git a/documentation/ref-manual/ref-features.xml b/documentation/ref-manual/ref-features.xml
index 7e1c5ef2f1..551db6535a 100644
--- a/documentation/ref-manual/ref-features.xml
+++ b/documentation/ref-manual/ref-features.xml
@@ -36,7 +36,7 @@
     <para>
         One method you can use to determine which recipes are checking to see if a
         particular feature is contained or not is to <filename>grep</filename> through
-        the <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        the <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
         for the feature.
         Here is an example that discovers the recipes whose build is potentially
         changed based on a given feature:
diff --git a/documentation/ref-manual/ref-release-process.xml b/documentation/ref-manual/ref-release-process.xml
index fe3ba0933e..aa1ff89a7d 100644
--- a/documentation/ref-manual/ref-release-process.xml
+++ b/documentation/ref-manual/ref-release-process.xml
@@ -63,7 +63,7 @@
         the
         <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>.
         The concept is that branches of
-        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
         with the same codename are likely to be compatible and thus
         work together.
         <note>
diff --git a/documentation/ref-manual/ref-structure.xml b/documentation/ref-manual/ref-structure.xml
index 424b8cc003..3b3f0779cd 100644
--- a/documentation/ref-manual/ref-structure.xml
+++ b/documentation/ref-manual/ref-structure.xml
@@ -42,7 +42,7 @@
             The copy usually matches the current stable BitBake release from
             the BitBake project.
             BitBake, a
-            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
             interpreter, reads the Yocto Project Metadata and runs the tasks
             defined by that data.
             Failures are usually from the Metadata and not from BitBake itself.
@@ -1023,7 +1023,7 @@
 
     <para>
         As mentioned previously,
-        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> is the core
+        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> is the core
         of the Yocto Project.
         Metadata has several important subdivisions:
     </para>
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index da4da8550d..632d78aa7e 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -1969,7 +1969,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the directory BitBake uses to store a cache
                     of the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
                     so it does not need to be parsed every time BitBake is
                     started.
                 </para>
@@ -3455,7 +3455,7 @@
                 <para>
                     Distribution configuration files are located in a
                     <filename>conf/distro</filename> directory within the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
                     that contains the distribution configuration.
                     The value for <filename>DISTRO</filename> must not contain
                     spaces, and is typically all lower-case.
@@ -7037,7 +7037,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Includes additional metadata from the Yocto Project kernel Git repository.
                     In the OpenEmbedded build system, the default Board Support Packages (BSPs)
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
                     is provided through
                     the <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>
                     and <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link> variables.
@@ -7839,7 +7839,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     defines the search
                     arguments used by the kernel tools to find the appropriate
                     description within the kernel
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
                     with which to build out the sources and configuration.
                     </para>
             </glossdef>
@@ -12620,7 +12620,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                         <listitem><para><emphasis><filename>file://</filename> -</emphasis>
                             Fetches files, which are usually files shipped with
                             the
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+                            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
                             from the local machine.
                             The path is relative to the
                             <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index 597bfbc55b..768f70186b 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -65,7 +65,7 @@
         <para>
             BitBake is the tool at the heart of the OpenEmbedded build system
             and is responsible for parsing the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
             generating a list of tasks from it, and then executing those tasks.
         </para>
 
@@ -152,7 +152,7 @@
         <para>
             Class files (<filename>.bbclass</filename>) contain information that
             is useful to share between
-            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> files.
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> files.
             An example is the
             <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
             class, which contains common settings for any application that
@@ -610,7 +610,7 @@
             The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
             "OEBasic" version but adds the task hash to the stamp files.
             This results in any
-            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
             change that changes the task hash, automatically
             causing the task to be run again.
             This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
diff --git a/documentation/sdk-manual/sdk-intro.xml b/documentation/sdk-manual/sdk-intro.xml
index 10af621a02..c2e43c2deb 100644
--- a/documentation/sdk-manual/sdk-intro.xml
+++ b/documentation/sdk-manual/sdk-intro.xml
@@ -93,7 +93,7 @@
                 matching sysroots (target and native) all built by the
                 OpenEmbedded build system (e.g. the SDK).
                 The toolchain and sysroots are based on a
-                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
                 configuration and extensions,
                 which allows you to cross-develop on the host machine for the
                 target hardware.