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>

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

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.

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

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.

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>

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

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.

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.

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>
 

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>:

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>
 

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

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:

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>

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>

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>

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>

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.