mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-30 00:20:08 +00:00
Code Issues Projects Releases Wiki Activity

documentation: Fixed links for "metadata" term.

Browse Source 
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>
This commit is contained in:
Scott Rifenbark
2017-06-14 06:59:22 -07:00
committed by Richard Purdie
parent 84d97de54a
commit f42d8f4cf0
18 changed files with 32 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/ref-manual/closer-look.xml
+1 -1
View File
@@ -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
+1 -1
View File
@@ -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
+2 -2
View File
@@ -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
+2 -2
View File
@@ -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
+1 -1
View File
@@ -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
+1 -1
View File
@@ -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
+2 -2
View File
@@ -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
+5 -5
View File
@@ -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
+3 -3
View File
@@ -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>