mirror of
https://git.yoctoproject.org/poky
synced 2026-06-01 13:09:50 +00:00
dev-manual: Completed rewrite of runtime package management
Fixes [YOCTO #12419] This section was unclear and needed some work. I added text to help clear things up. (From yocto-docs rev: 54358a39a5710dbd0cbcfe8dafd2f641ec3863ef) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
committed by
Richard Purdie
parent
8986a6f589
commit
e5702bce4a
@@ -34,11 +34,11 @@
|
|||||||
<para>
|
<para>
|
||||||
It is very easy to create your own layers to use with the
|
It is very easy to create your own layers to use with the
|
||||||
OpenEmbedded build system.
|
OpenEmbedded build system.
|
||||||
The Yocto Project ships with scripts that speed up creating
|
The Yocto Project ships with tools that speed up creating
|
||||||
general layers and BSP layers.
|
layers.
|
||||||
This section describes the steps you perform by hand to create
|
This section describes the steps you perform by hand to create
|
||||||
a layer so that you can better understand them.
|
a layer so that you can better understand them.
|
||||||
For information about the layer-creation scripts, see the
|
For information about the layer-creation tools, see the
|
||||||
"<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-bitbake-layers-script'>Creating a New BSP Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
|
"<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-bitbake-layers-script'>Creating a New BSP Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
|
||||||
section in the Yocto Project Board Support Package (BSP)
|
section in the Yocto Project Board Support Package (BSP)
|
||||||
Developer's Guide and the
|
Developer's Guide and the
|
||||||
@@ -47,9 +47,11 @@
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Follow these general steps to create your layer without the aid of a script:
|
Follow these general steps to create your layer without using
|
||||||
|
tools:
|
||||||
<orderedlist>
|
<orderedlist>
|
||||||
<listitem><para><emphasis>Check Existing Layers:</emphasis>
|
<listitem><para>
|
||||||
|
<emphasis>Check Existing Layers:</emphasis>
|
||||||
Before creating a new layer, you should be sure someone
|
Before creating a new layer, you should be sure someone
|
||||||
has not already created a layer containing the Metadata
|
has not already created a layer containing the Metadata
|
||||||
you need.
|
you need.
|
||||||
@@ -57,19 +59,31 @@
|
|||||||
<ulink url='http://layers.openembedded.org/layerindex/layers/'><filename>OpenEmbedded Metadata Index</filename></ulink>
|
<ulink url='http://layers.openembedded.org/layerindex/layers/'><filename>OpenEmbedded Metadata Index</filename></ulink>
|
||||||
for a list of layers from the OpenEmbedded community
|
for a list of layers from the OpenEmbedded community
|
||||||
that can be used in the Yocto Project.
|
that can be used in the Yocto Project.
|
||||||
|
You could find a layer that is identical or close to
|
||||||
|
what you need.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para><emphasis>Create a Directory:</emphasis>
|
<listitem><para>
|
||||||
|
<emphasis>Create a Directory:</emphasis>
|
||||||
Create the directory for your layer.
|
Create the directory for your layer.
|
||||||
While not strictly required, prepend the name of the
|
While not strictly required, prepend the name of the
|
||||||
folder with the string <filename>meta-</filename>.
|
directory with the string "meta-".
|
||||||
For example:
|
For example:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
meta-mylayer
|
meta-mylayer
|
||||||
meta-GUI_xyz
|
meta-GUI_xyz
|
||||||
meta-mymachine
|
meta-mymachine
|
||||||
</literallayout>
|
</literallayout>
|
||||||
|
Realize that the name of your layer does not include
|
||||||
|
the "meta-" string.
|
||||||
|
For example, the names of the previous three layers
|
||||||
|
are "mylayer", "GUI_xyz", and "mymachine".
|
||||||
|
Following this layer directory naming convention can
|
||||||
|
save you trouble later when tools or components
|
||||||
|
"assume" your layer resides in a directory whose name
|
||||||
|
starts with "meta-".
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para><emphasis>Create a Layer Configuration
|
<listitem><para>
|
||||||
|
<emphasis>Create a Layer Configuration
|
||||||
File:</emphasis>
|
File:</emphasis>
|
||||||
Inside your new layer folder, you need to create a
|
Inside your new layer folder, you need to create a
|
||||||
<filename>conf/layer.conf</filename> file.
|
<filename>conf/layer.conf</filename> file.
|
||||||
@@ -77,9 +91,14 @@
|
|||||||
file and copy that to your layer's
|
file and copy that to your layer's
|
||||||
<filename>conf</filename> directory and then modify the
|
<filename>conf</filename> directory and then modify the
|
||||||
file as needed.</para>
|
file as needed.</para>
|
||||||
|
|
||||||
<para>The
|
<para>The
|
||||||
<filename>meta-yocto-bsp/conf/layer.conf</filename> file
|
<filename>meta-yocto-bsp/conf/layer.conf</filename> file
|
||||||
demonstrates the required syntax:
|
in the Yocto Project
|
||||||
|
<ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
|
||||||
|
demonstrates the required syntax.
|
||||||
|
For your layer, you need to replace "yoctobsp" with the
|
||||||
|
root name of your layer:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
# We have a conf and classes directory, add to BBPATH
|
# We have a conf and classes directory, add to BBPATH
|
||||||
BBPATH .= ":${LAYERDIR}"
|
BBPATH .= ":${LAYERDIR}"
|
||||||
@@ -91,35 +110,41 @@
|
|||||||
BBFILE_COLLECTIONS += "yoctobsp"
|
BBFILE_COLLECTIONS += "yoctobsp"
|
||||||
BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
|
BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
|
||||||
BBFILE_PRIORITY_yoctobsp = "5"
|
BBFILE_PRIORITY_yoctobsp = "5"
|
||||||
LAYERVERSION_yoctobsp = "3"
|
LAYERVERSION_yoctobsp = "4"
|
||||||
|
LAYERSERIES_COMPAT_yoctobsp = "&DISTRO_NAME_NO_CAP;"
|
||||||
</literallayout></para>
|
</literallayout></para>
|
||||||
|
|
||||||
<para>Here is an explanation of the example:
|
<para>Here is an explanation of the example:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para>The configuration and
|
<listitem><para>
|
||||||
classes directory is appended to
|
The configuration and classes directory is
|
||||||
|
appended to
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBPATH'><filename>BBPATH</filename></ulink>.
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBPATH'><filename>BBPATH</filename></ulink>.
|
||||||
<note>
|
<note>
|
||||||
All non-distro layers, which include all BSP
|
All non-distro layers, which include all BSP
|
||||||
layers, are expected to append the layer
|
layers, are expected to append the layer
|
||||||
directory to the
|
directory to <filename>BBPATH</filename>.
|
||||||
<filename>BBPATH</filename>.
|
|
||||||
On the other hand, distro layers, such as
|
On the other hand, distro layers, such as
|
||||||
<filename>meta-poky</filename>, can choose
|
<filename>meta-poky</filename>, can choose
|
||||||
to enforce their own precedence over
|
to enforce their own precedence over
|
||||||
<filename>BBPATH</filename>.
|
<filename>BBPATH</filename>.
|
||||||
For an example of that syntax, see the
|
For an example of that syntax, see the
|
||||||
<filename>layer.conf</filename> file for
|
<filename>meta-poky/conf/layer.conf</filename>
|
||||||
the <filename>meta-poky</filename> layer.
|
file for in the Source Repositories.
|
||||||
</note></para></listitem>
|
</note>
|
||||||
<listitem><para>The recipes for the layers are
|
</para></listitem>
|
||||||
appended to
|
<listitem><para>
|
||||||
|
The recipes for the layers are appended to
|
||||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILES'>BBFILES</ulink></filename>.
|
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILES'>BBFILES</ulink></filename>.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para>The
|
<listitem><para>
|
||||||
|
The
|
||||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</ulink></filename>
|
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</ulink></filename>
|
||||||
variable is then appended with the layer name.
|
variable is then appended with the layer name,
|
||||||
|
which is "yoctobsp" in this example.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para>The
|
<listitem><para>
|
||||||
|
The
|
||||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PATTERN'>BBFILE_PATTERN</ulink></filename>
|
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PATTERN'>BBFILE_PATTERN</ulink></filename>
|
||||||
variable is set to a regular expression and is
|
variable is set to a regular expression and is
|
||||||
used to match files from
|
used to match files from
|
||||||
@@ -127,24 +152,34 @@
|
|||||||
layer.
|
layer.
|
||||||
In this case,
|
In this case,
|
||||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
|
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
|
||||||
is used to make <filename>BBFILE_PATTERN</filename> match within the
|
is used to make
|
||||||
layer's path.</para></listitem>
|
<filename>BBFILE_PATTERN</filename> match
|
||||||
<listitem><para>The
|
within the layer's path.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para>
|
||||||
|
The
|
||||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY'>BBFILE_PRIORITY</ulink></filename>
|
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY'>BBFILE_PRIORITY</ulink></filename>
|
||||||
variable then assigns a priority to the layer.
|
variable then assigns a priority to the layer.
|
||||||
Applying priorities is useful in situations
|
Applying priorities is useful in situations
|
||||||
where the same recipe might appear in multiple
|
where the same recipe might appear in multiple
|
||||||
layers and allows you to choose the layer
|
layers.
|
||||||
that takes precedence.</para></listitem>
|
A priority allows you to choose the layer
|
||||||
<listitem><para>The
|
that takes precedence.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para>
|
||||||
|
The
|
||||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERVERSION'>LAYERVERSION</ulink></filename>
|
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERVERSION'>LAYERVERSION</ulink></filename>
|
||||||
variable optionally specifies the version of a
|
variable optionally specifies the version of a
|
||||||
layer as a single number.</para></listitem>
|
layer as a single number.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para>
|
||||||
|
The
|
||||||
|
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
|
||||||
|
variable expands to the directory of the
|
||||||
|
current layer
|
||||||
|
</list></listitem>
|
||||||
</itemizedlist></para>
|
</itemizedlist></para>
|
||||||
<para>Note the use of the
|
|
||||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
|
|
||||||
variable, which expands to the directory of the current
|
|
||||||
layer.</para>
|
|
||||||
<para>Through the use of the <filename>BBPATH</filename>
|
<para>Through the use of the <filename>BBPATH</filename>
|
||||||
variable, BitBake locates class files
|
variable, BitBake locates class files
|
||||||
(<filename>.bbclass</filename>),
|
(<filename>.bbclass</filename>),
|
||||||
@@ -156,10 +191,11 @@
|
|||||||
This is similar to the way the <filename>PATH</filename>
|
This is similar to the way the <filename>PATH</filename>
|
||||||
variable is used for binaries.
|
variable is used for binaries.
|
||||||
It is recommended, therefore, that you use unique
|
It is recommended, therefore, that you use unique
|
||||||
class and configuration
|
class and configuration filenames in your custom layer.
|
||||||
filenames in your custom layer.</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para><emphasis>Add Content:</emphasis> Depending
|
<listitem><para>
|
||||||
on the type of layer, add the content.
|
<emphasis>Add Content:</emphasis>
|
||||||
|
Depending on the type of layer, add the content.
|
||||||
If the layer adds support for a machine, add the machine
|
If the layer adds support for a machine, add the machine
|
||||||
configuration in a <filename>conf/machine/</filename>
|
configuration in a <filename>conf/machine/</filename>
|
||||||
file within the layer.
|
file within the layer.
|
||||||
@@ -169,7 +205,8 @@
|
|||||||
If the layer introduces new recipes, put the recipes
|
If the layer introduces new recipes, put the recipes
|
||||||
you need in <filename>recipes-*</filename>
|
you need in <filename>recipes-*</filename>
|
||||||
subdirectories within the layer.
|
subdirectories within the layer.
|
||||||
<note>In order to be compliant with the Yocto Project,
|
<note>
|
||||||
|
In order to be compliant with the Yocto Project,
|
||||||
a layer must contain a
|
a layer must contain a
|
||||||
<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-readme'>README file.</ulink>
|
<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-readme'>README file.</ulink>
|
||||||
</note>
|
</note>
|
||||||
@@ -8835,11 +8872,13 @@ Some notes from Cal:
|
|||||||
During a build, BitBake always transforms a recipe into one or
|
During a build, BitBake always transforms a recipe into one or
|
||||||
more packages.
|
more packages.
|
||||||
For example, BitBake takes the <filename>bash</filename> recipe
|
For example, BitBake takes the <filename>bash</filename> recipe
|
||||||
and currently produces the <filename>bash-dbg</filename>,
|
and produces a number of packages (e.g.
|
||||||
<filename>bash-staticdev</filename>,
|
<filename>bash</filename>, <filename>bash-bashbug</filename>,
|
||||||
<filename>bash-dev</filename>, <filename>bash-doc</filename>,
|
<filename>bash-completion</filename>,
|
||||||
<filename>bash-locale</filename>, and
|
<filename>bash-completion-dbg</filename>,
|
||||||
<filename>bash</filename> packages.
|
<filename>bash-completion-dev</filename>,
|
||||||
|
<filename>bash-completion-extra</filename>,
|
||||||
|
<filename>bash-dbg</filename>, and so forth).
|
||||||
Not all generated packages are included in an image.
|
Not all generated packages are included in an image.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@@ -8883,7 +8922,7 @@ Some notes from Cal:
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
In order to use runtime package management, you
|
In order to use runtime package management, you
|
||||||
need a host/server machine that serves up the pre-compiled
|
need a host or server machine that serves up the pre-compiled
|
||||||
packages plus the required metadata.
|
packages plus the required metadata.
|
||||||
You also need package manipulation tools on the target.
|
You also need package manipulation tools on the target.
|
||||||
The build machine is a likely candidate to act as the server.
|
The build machine is a likely candidate to act as the server.
|
||||||
@@ -8891,6 +8930,10 @@ Some notes from Cal:
|
|||||||
package server.
|
package server.
|
||||||
The build machine could push its artifacts to another machine
|
The build machine could push its artifacts to another machine
|
||||||
that acts as the server (e.g. Internet-facing).
|
that acts as the server (e.g. Internet-facing).
|
||||||
|
In fact, doing so is advantageous for a production
|
||||||
|
environment as getting the packages away from the
|
||||||
|
development system's build directory prevents accidental
|
||||||
|
overwrites.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@@ -8900,11 +8943,11 @@ Some notes from Cal:
|
|||||||
out into a couple of different package groupings based on
|
out into a couple of different package groupings based on
|
||||||
criteria such as the target's CPU architecture, the target
|
criteria such as the target's CPU architecture, the target
|
||||||
board, or the C library used on the target.
|
board, or the C library used on the target.
|
||||||
For example, a build targeting the <filename>qemuarm</filename>
|
For example, a build targeting the <filename>qemux86</filename>
|
||||||
device produces the following three package databases:
|
device produces the following three package databases:
|
||||||
<filename>all</filename>, <filename>armv5te</filename>, and
|
<filename>noarch</filename>, <filename>i586</filename>, and
|
||||||
<filename>qemuarm</filename>.
|
<filename>qemux86</filename>.
|
||||||
If you wanted your <filename>qemuarm</filename> device to be
|
If you wanted your <filename>qemux86</filename> device to be
|
||||||
aware of all the packages that were available to it,
|
aware of all the packages that were available to it,
|
||||||
you would need to point it to each of these databases
|
you would need to point it to each of these databases
|
||||||
individually.
|
individually.
|
||||||
@@ -8950,10 +8993,10 @@ Some notes from Cal:
|
|||||||
PACKAGE_CLASSES ?= “package_<replaceable>packageformat</replaceable>”
|
PACKAGE_CLASSES ?= “package_<replaceable>packageformat</replaceable>”
|
||||||
</literallayout>
|
</literallayout>
|
||||||
where <replaceable>packageformat</replaceable>
|
where <replaceable>packageformat</replaceable>
|
||||||
can be "ipk", "rpm", and "deb", which are the
|
can be "ipk", "rpm", "deb", or "tar" which are the
|
||||||
supported package formats.
|
supported package formats.
|
||||||
<note>
|
<note>
|
||||||
Because the Yocto Project supports three
|
Because the Yocto Project supports four
|
||||||
different package formats, you can set the
|
different package formats, you can set the
|
||||||
variable with more than one argument.
|
variable with more than one argument.
|
||||||
However, the OpenEmbedded build system only
|
However, the OpenEmbedded build system only
|
||||||
@@ -8972,12 +9015,12 @@ Some notes from Cal:
|
|||||||
"package-management" in the
|
"package-management" in the
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>
|
||||||
variable.
|
variable.
|
||||||
Including "package-management" in this
|
Including "package-management" in this configuration
|
||||||
configuration variable ensures that when the image
|
variable ensures that when the image is assembled for your
|
||||||
is assembled for your target, the image includes
|
target, the image includes the currently-known package
|
||||||
the currently-known package databases as well as
|
databases as well as the target-specific tools required
|
||||||
the target-specific tools required for runtime
|
for runtime package management to be performed on the
|
||||||
package management to be performed on the target.
|
target.
|
||||||
However, this is not strictly necessary.
|
However, this is not strictly necessary.
|
||||||
You could start your image off without any databases
|
You could start your image off without any databases
|
||||||
but only include the required on-target package
|
but only include the required on-target package
|
||||||
@@ -8991,21 +9034,26 @@ Some notes from Cal:
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Whenever you perform any sort of build step that can
|
Whenever you perform any sort of build step that can
|
||||||
potentially generate a package or modify an existing
|
potentially generate a package or modify existing
|
||||||
package, it is always a good idea to re-generate the
|
package, it is always a good idea to re-generate the
|
||||||
package index with:
|
package index after the build by using the following
|
||||||
|
command:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
$ bitbake package-index
|
$ bitbake package-index
|
||||||
</literallayout>
|
</literallayout>
|
||||||
Realize that it is not sufficient to simply do the
|
It might be tempting to build the package and the
|
||||||
following:
|
package index at the same time with a command such as
|
||||||
|
the following:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
$ bitbake <replaceable>some-package</replaceable> package-index
|
$ bitbake <replaceable>some-package</replaceable> package-index
|
||||||
</literallayout>
|
</literallayout>
|
||||||
The reason for this restriction is because BitBake does not
|
Do not do this as BitBake does not schedule the package
|
||||||
properly schedule the <filename>package-index</filename>
|
index for after the completion of the package you are
|
||||||
target fully after any other target has completed.
|
building.
|
||||||
Thus, be sure to run the package update step separately.
|
Consequently, you cannot be sure of the package index
|
||||||
|
including information for the package you just built.
|
||||||
|
Thus, be sure to run the package update step separately
|
||||||
|
after building any packages.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@@ -9030,8 +9078,8 @@ Some notes from Cal:
|
|||||||
For example, if
|
For example, if
|
||||||
<filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink><filename>}</filename>
|
<filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink><filename>}</filename>
|
||||||
is <filename>tmp</filename> and your selected package type
|
is <filename>tmp</filename> and your selected package type
|
||||||
is IPK, then your IPK packages are available in
|
is RPM, then your RPM packages are available in
|
||||||
<filename>tmp/deploy/ipk</filename>.
|
<filename>tmp/deploy/rpm</filename>.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
@@ -9086,17 +9134,39 @@ Some notes from Cal:
|
|||||||
<title>Using RPM</title>
|
<title>Using RPM</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <filename>dnf</filename> application performs
|
The
|
||||||
runtime package management of RPM packages.
|
<ulink url='https://en.wikipedia.org/wiki/DNF_(software)'>Dandified Packaging Tool</ulink>
|
||||||
You must perform an initial setup for
|
(DNF) performs runtime package management of RPM
|
||||||
<filename>dnf</filename> on the target machine
|
packages.
|
||||||
if the
|
In order to use DNF for runtime package management,
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_ARCHS'><filename>PACKAGE_FEED_ARCHS</filename></ulink>,
|
you must perform an initial setup on the target
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_BASE_PATHS'><filename>PACKAGE_FEED_BASE_PATHS</filename></ulink>,
|
machine for cases where the
|
||||||
and
|
<filename>PACKAGE_FEED_*</filename> variables were not
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_URIS'><filename>PACKAGE_FEED_URIS</filename></ulink>
|
set as part of the image that is running on the
|
||||||
variables have not been set or the target image was
|
target.
|
||||||
built before the variables were set.
|
This means if you built your image and did not not use
|
||||||
|
these variables as part of the build and your image is
|
||||||
|
now running on the target, you need to perform the
|
||||||
|
steps in this section if you want to use runtime
|
||||||
|
package management.
|
||||||
|
<note>
|
||||||
|
For information on the
|
||||||
|
<filename>PACKAGE_FEED_*</filename> variables, see
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_ARCHS'><filename>PACKAGE_FEED_ARCHS</filename></ulink>,
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_BASE_PATHS'><filename>PACKAGE_FEED_BASE_PATHS</filename></ulink>,
|
||||||
|
and
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_URIS'><filename>PACKAGE_FEED_URIS</filename></ulink>
|
||||||
|
in the Yocto Project Reference Manual variables
|
||||||
|
glossary.
|
||||||
|
</note>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
On the target, you must inform DNF that package
|
||||||
|
databases are available.
|
||||||
|
You do this by creating a file named
|
||||||
|
<filename>/etc/yum.repos.d/oe-packages.repo</filename>
|
||||||
|
and defining the <filename>oe-packages</filename>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@@ -9105,21 +9175,60 @@ Some notes from Cal:
|
|||||||
<filename>all</filename>, <filename>i586</filename>,
|
<filename>all</filename>, <filename>i586</filename>,
|
||||||
and <filename>qemux86</filename> from a server named
|
and <filename>qemux86</filename> from a server named
|
||||||
<filename>my.server</filename>.
|
<filename>my.server</filename>.
|
||||||
You must inform <filename>dnf</filename> of the
|
The specifics for setting up the web server are up to
|
||||||
availability of these databases by creating a
|
you.
|
||||||
<filename>/etc/yum.repos.d/oe-packages.repo</filename>
|
The critical requirement is that the URIs in the
|
||||||
file with the following content:
|
target repository configuration point to the
|
||||||
<literallayout class='monospaced'>
|
correct remote location for the feeds.
|
||||||
|
This example uses a location outside of the build
|
||||||
|
system's <filename>deploy</filename> directory.
|
||||||
|
Realize that it is possible to run a web server
|
||||||
|
that gets the databases from
|
||||||
|
<filename>deploy</filename> directory where the image
|
||||||
|
was built.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
When telling DNF where to look for the package
|
||||||
|
databases, you must declare individual locations
|
||||||
|
per architecture or a single location used for all
|
||||||
|
architectures.
|
||||||
|
You cannot do both:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem><para>
|
||||||
|
<emphasis>Create an Explicit List of Architectures:</emphasis>
|
||||||
|
Define individual base URLs to identify where
|
||||||
|
each package database is located:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
[oe-packages]
|
[oe-packages]
|
||||||
baseurl=http://my.server http://my.server/rpm/qemux86 http://my.server/rpm/all
|
baseurl=http://my.server/rpm/i586 http://my.server/rpm/qemux86 http://my.server/rpm/all
|
||||||
</literallayout>
|
</literallayout>
|
||||||
From the target machine, fetch the repository:
|
This example informs DNF about individual
|
||||||
|
package databases for all three architectures.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para>
|
||||||
|
<emphasis>Create a Single (Full) Package Index:</emphasis>
|
||||||
|
Define a single base URL that identifies where
|
||||||
|
a full package database is located:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
[oe-packages]
|
||||||
|
baseurl=http://my.server/rpm
|
||||||
|
</literallayout>
|
||||||
|
This example informs DNF about a single package
|
||||||
|
database that contains all the package index
|
||||||
|
information for all supported architectures.
|
||||||
|
</para></listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Once you have informed DNF where to find the package
|
||||||
|
databases, you need to fetch them:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
# dnf makecache
|
# dnf makecache
|
||||||
</literallayout>
|
</literallayout>
|
||||||
After everything is set up, <filename>dnf</filename>
|
DNF is now able to find, install, and upgrade packages
|
||||||
is able to find, install, and upgrade packages from
|
from the specified repository or repositories.
|
||||||
the specified repository.
|
|
||||||
<note>
|
<note>
|
||||||
See the
|
See the
|
||||||
<ulink url='http://dnf.readthedocs.io/en/latest/'>DNF documentation</ulink>
|
<ulink url='http://dnf.readthedocs.io/en/latest/'>DNF documentation</ulink>
|
||||||
|
|||||||
Reference in New Issue
Block a user