[FE training-materials-updates] yocto: fix the mix up of packages, recipes and applications
Antoine Ténart
antoine.tenart at free-electrons.com
Mon May 22 13:45:03 CEST 2017
Repository : git://git.free-electrons.com/training-materials.git
On branch : master
Link : http://git.free-electrons.com/training-materials/commit/?id=228cf442f7a4e2bf8da1144bae324ec7340771e4
>---------------------------------------------------------------
commit 228cf442f7a4e2bf8da1144bae324ec7340771e4
Author: Antoine Tenart <antoine.tenart at free-electrons.com>
Date: Mon May 22 13:44:57 2017 +0200
yocto: fix the mix up of packages, recipes and applications
Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
>---------------------------------------------------------------
228cf442f7a4e2bf8da1144bae324ec7340771e4
.../yocto-add-application.tex | 6 +--
labs/yocto-extend-recipe/yocto-extend-recipe.tex | 2 +-
slides/yocto-advanced/yocto-advanced.tex | 17 +++----
slides/yocto-basics/yocto-basics.tex | 8 ++--
slides/yocto-layer-distro/yocto-layer-distro.tex | 4 +-
slides/yocto-layer/yocto-layer.tex | 8 ++--
slides/yocto-overview/yocto-overview.tex | 7 ++-
.../yocto-recipe-advanced.tex | 10 ++---
slides/yocto-recipe-basics/yocto-recipe-basics.tex | 52 +++++++++++-----------
.../yocto-runtime-package-management.tex | 2 +-
slides/yocto-sdk/yocto-sdk.tex | 14 +++---
11 files changed, 63 insertions(+), 67 deletions(-)
diff --git a/labs/yocto-add-application/yocto-add-application.tex b/labs/yocto-add-application/yocto-add-application.tex
index 4a35797..5a1cc70 100644
--- a/labs/yocto-add-application/yocto-add-application.tex
+++ b/labs/yocto-add-application/yocto-add-application.tex
@@ -37,7 +37,7 @@ look: license, Makefile, requirements\dots
Create an appropriate common file, ending in \code{.inc}
-In this file add the common configuration variables: source URI, package
+In this file add the common configuration variables: source URI,
description\dots
\section{Write the version specific recipe}
@@ -57,7 +57,7 @@ bitbake ninvaders
\end{verbatim}
Try to make the recipe on your own. Also eliminate the warnings related to your
-package: some configuration variables are not mandatory but it is a very good
+recipe: some configuration variables are not mandatory but it is a very good
practice to define them all.
If you hang on a problem, check the following points:
@@ -77,7 +77,7 @@ to add some Makefile's options, you should look for it.
\section{Update the rootfs and test}
-Now that you've compiled the \code{nInvaders} package, generate a new
+Now that you've compiled the \code{nInvaders} application, generate a new
rootfs image with \code{bitbake core-image-minimal}. Then update the
NFS root directory. You can confirm the \code{nInvaders} program is
present by running:
diff --git a/labs/yocto-extend-recipe/yocto-extend-recipe.tex b/labs/yocto-extend-recipe/yocto-extend-recipe.tex
index 204140d..9897200 100644
--- a/labs/yocto-extend-recipe/yocto-extend-recipe.tex
+++ b/labs/yocto-extend-recipe/yocto-extend-recipe.tex
@@ -10,7 +10,7 @@ During this lab, you will:
\section{Create a basic appended recipe}
To avoid rewriting recipes when a modification is needed on an already existing
-package, BitBake allows to extend recipes and to overwrite, append or prepend
+one, BitBake allows to extend recipes and to overwrite, append or prepend
configuration variables values through the so-called BitBake append files.
We will first create a basic BitBake append file, without any change made
diff --git a/slides/yocto-advanced/yocto-advanced.tex b/slides/yocto-advanced/yocto-advanced.tex
index 639ebc3..7fe5831 100644
--- a/slides/yocto-advanced/yocto-advanced.tex
+++ b/slides/yocto-advanced/yocto-advanced.tex
@@ -13,7 +13,7 @@
\frametitle{A little reminder}
\begin{itemize}
\item {\em Recipes} describe how to fetch, configure, compile and
- install packages.
+ install applications.
\item These tasks can be run independently (if their dependencies
are met).
\item All available packages in Poky are not selected by default
@@ -261,7 +261,7 @@ IMAGE_INSTALL = "busybox mtd-utils"
versions
\item[\code{-f}] force the given task to be run by removing its
stamp file
- \item[\code{world}] keyword for all packages
+ \item[\code{world}] keyword for all recipes
\item[\code{-b <recipe>}] execute tasks from the given
\code{recipe} (without resolving dependencies).
\end{description}
@@ -273,21 +273,22 @@ IMAGE_INSTALL = "busybox mtd-utils"
\begin{itemize}
\item \code{bitbake -c listtasks virtual/kernel}
\begin{itemize}
- \item Gives a list of the available tasks for the package
- \code{virtual/kernel}. Tasks are prefixed with \code{do_}.
+ \item Gives a list of the available tasks for the recipe
+ providing the package \code{virtual/kernel}. Tasks are
+ prefixed with \code{do_}.
\end{itemize}
\item \code{bitbake -c menuconfig virtual/kernel}
\begin{itemize}
- \item Execute the task \code{menuconfig} on the kernel package.
+ \item Execute the task \code{menuconfig} on the recipe providing
+ the \code{virtual/kernel} package.
\end{itemize}
\item \code{bitbake -f dropbear}
\begin{itemize}
- \item Force the \code{dropbear} package to be rebuilt from
- scratch.
+ \item Force the \code{dropbear} recipe to run all tasks.
\end{itemize}
\item \code{bitbake -c fetchall world}
\begin{itemize}
- \item Download all package sources and their dependencies.
+ \item Download all recipe sources and their dependencies.
\end{itemize}
\item For a full description: \code{bitbake --help}
\end{itemize}
diff --git a/slides/yocto-basics/yocto-basics.tex b/slides/yocto-basics/yocto-basics.tex
index 40173ff..9d9d930 100644
--- a/slides/yocto-basics/yocto-basics.tex
+++ b/slides/yocto-basics/yocto-basics.tex
@@ -58,7 +58,7 @@
\frametitle{Available commands}
\begin{description}[style=nextline]
\item[bitbake] The main build engine command. Used to perform
- tasks on available packages (download, configure, compile\dots).
+ tasks on available recipes (download, configure, compile\dots).
\item[bitbake-*] Various specific commands related to the BitBake
build engine.
\item[yocto-layer] Command to create a new generic layer.
@@ -71,7 +71,7 @@
\begin{description}[style=nextline]
\item[conf/] Configuration files. Image specific and layer
configuration.
- \item[downloads/] Downloaded upstream tarballs of the packages
+ \item[downloads/] Downloaded upstream tarballs of the recipes
used in the builds.
\item[sstate-cache/] Shared state cache. Used by all builds.
\item[tmp/] Holds all the build system outputs.
@@ -92,7 +92,7 @@
packages. Contains the patched sources, generated objects and
logs.
\item[tmp/sysroots/] Shared libraries and headers used to compile
- packages for the target but also for the host.
+ applications for the target but also for the host.
\end{description}
\end{frame}
@@ -124,8 +124,6 @@
compiling. Defaults to the number of CPUs on the system.
\item[MACHINE] The machine the target is built for, e.g.
\code{beaglebone}.
- \item[PACKAGE\_CLASSES] Packages format (\code{deb}, \code{ipk}
- or \code{rpm}).
\end{description}
\end{itemize}
\end{frame}
diff --git a/slides/yocto-layer-distro/yocto-layer-distro.tex b/slides/yocto-layer-distro/yocto-layer-distro.tex
index e8405ee..86f4e2b 100644
--- a/slides/yocto-layer-distro/yocto-layer-distro.tex
+++ b/slides/yocto-layer-distro/yocto-layer-distro.tex
@@ -31,7 +31,7 @@
\item Configuration files.
\item Specific classes.
\item Distribution specific recipes: initialization scripts,
- splash screen packages\dots
+ splash screen\dots
\end{itemize}
\end{itemize}
\end{frame}
@@ -71,7 +71,7 @@ MAINTAINER = "..."
included.
\begin{itemize}
\item This configures the toolchain to use by defining preferred
- providers and versions for packages such as \code{gcc},
+ providers and versions for recipes such as \code{gcc},
\code{binutils}, \code{*libc}\dots
\end{itemize}
\item The providers' recipes define how to compile or/and install
diff --git a/slides/yocto-layer/yocto-layer.tex b/slides/yocto-layer/yocto-layer.tex
index 3efff8b..b40e036 100644
--- a/slides/yocto-layer/yocto-layer.tex
+++ b/slides/yocto-layer/yocto-layer.tex
@@ -9,7 +9,7 @@
\emph{metadata}.
\item Layers allow to isolate and organize the metadata.
\begin{itemize}
- \item A layer is a collection of packages and build tasks.
+ \item A layer is a collection of recipes.
\end{itemize}
\item It is a good practice to begin a layer name with the prefix
\code{meta-}.
@@ -36,7 +36,7 @@
\item Poky is not a final set of layers. It is the common base.
\item Layers are added when needed.
\item When making modifications to the existing recipes or when
- adding new packages, it is a good practice not to modify Poky.
+ adding new ones, it is a good practice not to modify Poky.
Instead you can create your own layers!
\end{itemize}
\end{frame}
@@ -104,8 +104,8 @@
\item Many SoC specific layers are available, providing support
for the boards using these SoCs. Some examples: \code{meta-ti},
\code{meta-fsl-arm} and \code{meta-raspberrypi}.
- \item Other layers offer to support packages not available in the
- Poky reference system:
+ \item Other layers offer to support applications not available in
+ the Poky reference system:
\begin{itemize}
\item \code{meta-browser}: web browsers (Chromium, Firefox).
\item \code{meta-filesystems}: support for additional
diff --git a/slides/yocto-overview/yocto-overview.tex b/slides/yocto-overview/yocto-overview.tex
index 3e7a944..6b610f0 100644
--- a/slides/yocto-overview/yocto-overview.tex
+++ b/slides/yocto-overview/yocto-overview.tex
@@ -21,8 +21,8 @@
\item BitBake, the {\em build engine}. It is a task scheduler,
like \code{make}. It interprets configuration files and
recipes (also called {\em metadata}) to perform a set of
- tasks, to download, configure and build specified packages and
- filesystem images.
+ tasks, to download, configure and build specified applications
+ and filesystem images.
\item OpenEmbedded-Core, a set of base {\em layers}. It is a set
of recipes, layers and classes which are shared between all
OpenEmbedded based systems.
@@ -45,8 +45,7 @@
\item Organization of OpenEmbedded-Core:
\begin{itemize}
\item {\em Recipes} describe how to fetch, configure, compile
- and package applications and images. They have a specific
- syntax.
+ and applications and images. They have a specific syntax.
\item {\em Layers} are sets of recipes, matching a common
purpose. For Texas Instruments board support, the {\em
meta-ti} layer is used.
diff --git a/slides/yocto-recipe-advanced/yocto-recipe-advanced.tex b/slides/yocto-recipe-advanced/yocto-recipe-advanced.tex
index ef28350..806f780 100644
--- a/slides/yocto-recipe-advanced/yocto-recipe-advanced.tex
+++ b/slides/yocto-recipe-advanced/yocto-recipe-advanced.tex
@@ -109,7 +109,7 @@ SRC_URI += "file://custom-modification-0.patch \
variants}.
\item The virtual name is specified through the \code{PROVIDES}
variable.
- \item Several packages can provide the same virtual name. Only one
+ \item Several recipes can provide the same virtual name. Only one
will be built and installed into the generated image.
\item \code{PROVIDES = "virtual/kernel"}
\end{itemize}
@@ -121,13 +121,13 @@ SRC_URI += "file://custom-modification-0.patch \
\frametitle{Introduction to classes}
\begin{itemize}
\item Classes provide an abstraction to common code, which can be
- re-used in multiple packages.
+ re-used in multiple recipes.
\item Common tasks do not have to be re-developed!
\item Any metadata and task which can be put in a recipe can be
used in a class.
\item Classes extension is \code{.bbclass}
\item Classes are located in the \code{classes} folder of a layer.
- \item Packages can use this common code by inheriting a class:
+ \item Recipes can use this common code by inheriting a class:
\begin{itemize}
\item \code{inherit <class>}
\end{itemize}
@@ -154,7 +154,7 @@ SRC_URI += "file://custom-modification-0.patch \
\begin{itemize}
\item Every recipe inherits the base class automatically.
\item Contains a set of basic common tasks to fetch, unpack or
- compile packages.
+ compile applications.
\item Inherits other common classes, providing:
\begin{itemize}
\item Mirrors definitions: \code{DEBIAN_MIRROR},
@@ -191,7 +191,7 @@ SRC_URI += "file://custom-modification-0.patch \
\begin{frame}
\frametitle{The autotools class}
\begin{itemize}
- \item Defines tasks and metadata to handle packages using the
+ \item Defines tasks and metadata to handle applications using the
autotools build system (autoconf, automake and libtool):
\begin{itemize}
\item \code{do_configure}: generates the configure script using
diff --git a/slides/yocto-recipe-basics/yocto-recipe-basics.tex b/slides/yocto-recipe-basics/yocto-recipe-basics.tex
index a3dec15..aaf762e 100644
--- a/slides/yocto-recipe-basics/yocto-recipe-basics.tex
+++ b/slides/yocto-recipe-basics/yocto-recipe-basics.tex
@@ -11,7 +11,7 @@
\begin{frame}
\frametitle{Basics}
\begin{itemize}
- \item Recipes describe how to handle a given package.
+ \item Recipes describe how to handle a given application.
\item A recipe is a set of instructions to describe how to
retrieve, patch, compile, install and generate binary packages
for a given application.
@@ -19,7 +19,7 @@
required.
\item The recipes are parsed by the BitBake build engine.
\item The format of a recipe file name is
- \code{<package-name>_<version>.bb}
+ \code{<application-name>_<version>.bb}
\end{itemize}
\end{frame}
@@ -31,7 +31,7 @@
\item It also contains functions that can be run (fetch,
configure, compile\dots) which are called {\bf tasks}.
\item Tasks provide a set of actions to perform.
- \item Remember the \code{bitbake -c <task> <package>} command?
+ \item Remember the \code{bitbake -c <task> <target>} command?
\end{itemize}
\end{frame}
@@ -46,8 +46,7 @@
name
\item[PR] package release, defaults to \code{r0}
\end{description}
- \item The recipe name and version usually match the upstream
- package ones.
+ \item The recipe name and version usually match the upstream ones.
\item When using the recipe \code{bash_4.2.bb}:
\begin{itemize}
\item \code{${PN} = "bash"}
@@ -67,14 +66,14 @@
\begin{frame}
\frametitle{Organization of a recipe}
\begin{itemize}
- \item Many packages have more than one recipe, to support
+ \item Many applications have more than one recipe, to support
different versions. In that case the common metadata is
included in each version specific recipe and is in a \code{.inc}
file:
\begin{itemize}
- \item \code{<package>.inc}: version agnostic metadata.
- \item \code{<package>_<version>.bb}: \code{require
- <package>.inc} and version specific metadata.
+ \item \code{<application>.inc}: version agnostic metadata.
+ \item \code{<application>_<version>.bb}: \code{require
+ <application>.inc} and version specific metadata.
\end{itemize}
\item We can divide a recipe into three main parts:
\begin{itemize}
@@ -88,13 +87,13 @@
\begin{frame}
\frametitle{The header}
\begin{itemize}
- \item Configuration variables to describe the package:
+ \item Configuration variables to describe the application:
\begin{description}
\item[DESCRIPTION] describes what the software is about
\item[HOMEPAGE] URL to the project's homepage
\item[PRIORITY] defaults to \code{optional}
\item[SECTION] package category (e.g. \code{console/utils})
- \item[LICENSE] the package's license
+ \item[LICENSE] the application's license
\end{description}
\end{itemize}
\end{frame}
@@ -104,7 +103,7 @@
\begin{itemize}
\item We need to retrieve both the raw sources from an official
location and the resources needed to configure, patch or install
- the package.
+ the application.
\item \code{SRC_URI} defines where and how to retrieve the
needed elements. It is a set of URI schemes pointing to the
resource locations (local or remote).
@@ -132,7 +131,7 @@
\end{itemize}
\item The \code{http}, \code{https} and \code{ftp} schemes:
\begin{itemize}
- \item \code{https://example.com/package-1.0.tar.bz2}
+ \item \code{https://example.com/application-1.0.tar.bz2}
\item A few variables are available to help pointing to remote
locations: \code{${SOURCEFORGE_MIRROR}},
\code{${GNU_MIRROR}}, \code{${KERNELORG_MIRROR}}\dots
@@ -175,7 +174,7 @@ SRC_URI[patch.md5sum] = "b184acf9eb39df794ffd..."
\frametitle{The source locations: local files}
\begin{itemize}
\item All local files found in \code{SRC_URI} are copied into the
- package's working directory, in \code{build/tmp/work/}.
+ recipe's working directory, in \code{build/tmp/work/}.
\item The searched paths are defined in the \code{FILESPATH}
variable.
\end{itemize}
@@ -204,7 +203,7 @@ FILESOVERRIDES = "${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
\begin{itemize}
\item When extracting a tarball, BitBake expects to find the
extracted files in a directory named
- \code{<package-name>-<version>}. This is controlled by the
+ \code{<application>-<version>}. This is controlled by the
\code{S} variable. If the directory has another name, you must
explicitly define \code{S}.
\item If the scheme is \code{git}, \code{S} must be set to
@@ -238,33 +237,32 @@ LIC_FILES_CHKSUM = \
\begin{frame}
\frametitle{Dependencies 1/2}
\begin{itemize}
- \item A package can have dependencies during the build or at
+ \item A recipe can have dependencies during the build or at
runtime. To reflect these requirements in the recipe, two
variables are used:
\begin{description}
- \item[DEPENDS] List of the package build-time dependencies.
+ \item[DEPENDS] List of the recipe build-time dependencies.
\item[RDEPENDS] List of the package runtime
dependencies. Must be package specific (e.g. with
\code{_${PN}}).
\end{description}
- \item \code{DEPENDS = "package-b"}: the local \code{do_configure}
- task depends on the \code{do_populate_sysroot} task of package
- b.
- \item \code{RDEPENDS_${PN} = "package-b"}: the local
+ \item \code{DEPENDS = "recipe-b"}: the local \code{do_configure}
+ task depends on the \code{do_populate_sysroot} task of recipe-b.
+ \item \code{RDEPENDS_${PN} = "recipe-b"}: the local
\code{do_build} task depends on the
- \code{do_package_write_<archive-format>} task of package b.
+ \code{do_package_write_<archive-format>} task of recipe b.
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Dependencies 2/2}
\begin{itemize}
- \item Sometimes a package have dependencies on specific versions
- of another package.
+ \item Sometimes a recipe have dependencies on specific versions
+ of another recipe.
\item BitBake allows to reflect this by using:
\begin{itemize}
- \item \code{DEPENDS = "package-b (>= 1.2)"}
- \item \code{RDEPENDS_${PN} = "package-b (>= 1.2)"}
+ \item \code{DEPENDS = "recipe-b (>= 1.2)"}
+ \item \code{RDEPENDS_${PN} = "recipe-b (>= 1.2)"}
\end{itemize}
\item The following operators are supported: \code{=}, \code{>},
\code{<}, \code{>=} and \code{<=}.
@@ -301,7 +299,7 @@ LIC_FILES_CHKSUM = \
\begin{description}
\item[D] The destination directory (root directory of where
the files are installed, before creating the image).
- \item[WORKDIR] the package's working directory
+ \item[WORKDIR] the recipe's working directory
\end{description}
\item Syntax of a task:
\end{itemize}
diff --git a/slides/yocto-runtime-package-management/yocto-runtime-package-management.tex b/slides/yocto-runtime-package-management/yocto-runtime-package-management.tex
index 3171ca3..83aca91 100644
--- a/slides/yocto-runtime-package-management/yocto-runtime-package-management.tex
+++ b/slides/yocto-runtime-package-management/yocto-runtime-package-management.tex
@@ -3,7 +3,7 @@
\begin{frame}
\frametitle{Introduction}
\begin{itemize}
- \item BitBake always builds packages from the recipes selected in
+ \item BitBake always builds packages selected in
\code{IMAGE_INSTALL}.
\item The packages are used to generate the root filesystem.
\item It is also possible to update the system at runtime using these
diff --git a/slides/yocto-sdk/yocto-sdk.tex b/slides/yocto-sdk/yocto-sdk.tex
index 7056cc7..47ca3bf 100644
--- a/slides/yocto-sdk/yocto-sdk.tex
+++ b/slides/yocto-sdk/yocto-sdk.tex
@@ -265,10 +265,10 @@ $ make
and the development of OpenEmbedded recipes.
\item It can be used to:
\begin{itemize}
- \item Generate a recipe for a given upstream package.
- \item Modify an existing recipe and its package sources.
+ \item Generate a recipe for a given upstream application.
+ \item Modify an existing recipe and its associated sources.
\item Upgrade an existing recipe to use a newer upstream
- package.
+ application.
\end{itemize}
\item \code{Devtool} adds a new layer, automatically managed, in
\code{$BUILDDIR/workspace/}.
@@ -298,7 +298,7 @@ $ make
\code{devtool upgrade -V <version> <recipe>}
\begin{itemize}
\item Where \code{version} is the new version of the upstream
- package.
+ application.
\end{itemize}
\end{itemize}
\end{frame}
@@ -320,7 +320,7 @@ $ make
\frametitle{\code{devtool} usage 3/3}
\begin{itemize}
\item \code{devtool deploy-target <recipe> <target>}: upload the
- \code{recipe}'s package on \code{target}, which is a live
+ \code{recipe}'s packages on \code{target}, which is a live
running target with an SSH server running (\code{user at address}).
\item \code{devtool update-recipe <recipe>}: generate patches from
git commits made locally.
@@ -337,7 +337,7 @@ $ make
\begin{itemize}
\item Quilt is an utility to manage patches which can be used
without having a clean source tree.
- \item It can be used to create patches for packages already
+ \item It can be used to create patches for recipes already
available in the build system.
\item Be careful when using this workflow: the modifications won't
persist across builds!
@@ -354,7 +354,7 @@ $ make
\item Add files to this patch: \code{$ quilt add file0.c file1.c}
\item Make the modifications by editing the files.
\item Test the modifications:
- \code{$ bitbake -c compile -f package}
+ \code{$ bitbake -c compile -f recipe}
\item Generate the patch file: \code{$ quilt refresh}
\item Move the generated patch into the recipe's directory.
\end{enumerate}
More information about the training-materials-updates
mailing list