[FE training-materials-updates] yocto: slides: add a chapter about runtime package management
Antoine Ténart
antoine.tenart at free-electrons.com
Thu Jun 9 11:45:08 CEST 2016
Repository : git://git.free-electrons.com/training-materials.git
On branch : master
Link : http://git.free-electrons.com/training-materials/commit/?id=3b983fb80ed661a23478facd44601db3cabfc4d1
>---------------------------------------------------------------
commit 3b983fb80ed661a23478facd44601db3cabfc4d1
Author: Antoine Tenart <antoine.tenart at free-electrons.com>
Date: Thu Jun 9 11:03:01 2016 +0200
yocto: slides: add a chapter about runtime package management
Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
>---------------------------------------------------------------
3b983fb80ed661a23478facd44601db3cabfc4d1
Makefile | 1 +
slides/yocto-advanced/yocto-advanced.tex | 12 --
.../yocto-runtime-package-management.tex | 173 +++++++++++++++++++++
3 files changed, 174 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index 05b45e9..f963090 100644
--- a/Makefile
+++ b/Makefile
@@ -276,6 +276,7 @@ YOCTO_SLIDES = \
yocto-sdk-eclipse-lab \
yocto-licensing \
yocto-recipe-extra \
+ yocto-runtime-package-management \
yocto-resources \
last-slides
diff --git a/slides/yocto-advanced/yocto-advanced.tex b/slides/yocto-advanced/yocto-advanced.tex
index ba26e65..bd0b37f 100644
--- a/slides/yocto-advanced/yocto-advanced.tex
+++ b/slides/yocto-advanced/yocto-advanced.tex
@@ -235,18 +235,6 @@ IMAGE_INSTALL = "busybox mtd-utils"
\end{itemize}
\end{frame}
-\begin{frame}
- \frametitle{Format}
- \begin{itemize}
- \item By default, Poky uses the RPM package format
- \item OpenEmbedded-Core uses the IPK package format
- \item To select the generated package formats, use the
- \code{PACKAGE_CLASSES} variable
- \item Valid values are: \code{package_rpm},
- \code{package_deb}, \code{package_ipk} (multiple values are OK)
- \end{itemize}
-\end{frame}
-
\subsection{The power of BitBake}
\begin{frame}
diff --git a/slides/yocto-runtime-package-management/yocto-runtime-package-management.tex b/slides/yocto-runtime-package-management/yocto-runtime-package-management.tex
new file mode 100644
index 0000000..44fe75b
--- /dev/null
+++ b/slides/yocto-runtime-package-management/yocto-runtime-package-management.tex
@@ -0,0 +1,173 @@
+\section{Runtime Package Management}
+
+\begin{frame}
+ \frametitle{Introduction}
+ \begin{itemize}
+ \item BitBake always build packages from the recipes selected in
+ \code{IMAGE_INSTALL}.
+ \item The packages are used to generate the root filesystem.
+ \item It also possible to update the system at runtime using these
+ packages, for many use cases:
+ \begin{itemize}
+ \item In-field security updates.
+ \item System updates over the wire.
+ \item System, packages or configuration customization at
+ runtime.
+ \item Remote debugging.
+ \end{itemize}
+ \item Using the Runtime Package Management is an optional feature.
+ \item We'll use the IPK package format as an example in the
+ following slides.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Requirements}
+ \begin{itemize}
+ \item First of all, you need a server to serve the packages to a
+ private subnet or over the Internet. Packages are typically
+ served over \code{https} or \code{http}.
+ \item Specific tools are also required on the target, and must be
+ shipped on the product. They should be included into the images
+ generated by the build system.
+ \item These tools will be specific to the package type used.
+ \begin{itemize}
+ \item This is similar to Linux distributions: Debian is using
+ \code{.deb} related tools (dpkg, apt\dots) while Fedora uses
+ \code{.rpm} related ones (yum).
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\subsection{Build configuration}
+
+\begin{frame}
+ \frametitle{Build configuration 1/2}
+ \begin{itemize}
+ \item The \code{PACKAGE_CLASSES} variable controls which package
+ format to use. More than one can be used.
+ \item Valid values are \code{package_rpm}, \code{package_deb},
+ \code{package_ipk}.
+ \item By default Poky uses the RPM format, while OpenEmbedded-Core
+ uses the IPK one.
+ \item Example:
+ \begin{itemize}
+ \item \code{PACKAGE_CLASSES = "package_ipk"}
+ \item \code{PACKAGE_CLASSES = "package_rpm package_deb"}
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Build configuration 2/2}
+ To install the required tools on the target, there are two
+ possible solutions:
+ \begin{itemize}
+ \item By adding \code{package-management} to the images
+ features.
+ \begin{itemize}
+ \item The required tool will be installed on the target.
+ \item The package database corresponding to the build will be
+ installed as well.
+ \end{itemize}
+ \item Or by manually adding the required tools in
+ \code{IMAGE_INSTALL}. For example to use the IPK format we
+ need \code{opkg}.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Build considerations}
+ \begin{itemize}
+ \item The Runtime Package Management uses package databases to
+ store information about available packages and their version.
+ \item Whenever a build generates a new package or modifies an
+ existing one, the package database must be updated.
+ \item \code{$ bitbake package-index}
+ \item Be careful: BitBake does not properly schedule the
+ \code{package-index} target. You must use this target alone to
+ have a consistent package database.
+ \begin{itemize}
+ \item \code{$ bitbake ninvaders package-index} won't
+ necessarily generate an updated package database.
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\subsection{Package server configuration}
+
+\begin{frame}[fragile]
+ \frametitle{Apache2 example setup}
+ Apache2 HTTP setup for IPK packages. This should go in
+ \code{/etc/apache2/sites-enabled/package-server.conf}.
+ \begin{block}{}
+ \begin{minted}{sh}
+<VirtualHost:*:80>
+ ServerName packages.example.net
+
+ DocumentRoot /path/to/build/tmp/deploy/ipk
+ <Directory /path/to/build/tmp/deploy/ipk>
+ Options +Indexes
+ Order allow,deny
+ allow from all
+ </Directory>
+<VirtualHost>
+ \end{minted}
+ \end{block}
+\end{frame}
+
+\subsection{Target configuration}
+
+\begin{frame}[fragile]
+ \frametitle{The IPK runtime management software}
+ \begin{itemize}
+ \item The IPK runtime management software is \code{opkg}.
+ \item It can be configured using configurations files ending in
+ \code{.conf} in \code{/etc/opkg/}.
+ \item This configuration helps \code{opkg} to find the package
+ databases you want to use.
+ \item For example, with our previously configured package server:
+ \begin{block}{}
+ \begin{minted}{sh}
+src/gz all http://packages.example.net/all
+src/gz armv7a http://packages.example.net/armv7a
+src/gz beaglebone http://packages.example.net/beaglebone
+ \end{minted}
+ \end{block}
+ \item This can be automatically generated by defining the
+ \code{FEED_DEPLOYDIR_BASE_URI} variable. This is specific to the
+ IPK format.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{\code{opkg} usage}
+ \begin{itemize}
+ \item \code{opkg update}: fetch and update the package
+ databases, from the remote package servers.
+ \item \code{opkg list}: list available packages.
+ \item \code{opkg upgrade}: upgrade all installed packages.
+ \item \code{opkg upgrade <package>}: upgrade one package
+ explicitly.
+ \item \code{opkg install <package>}: install a specific package.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}[fragile]
+ \frametitle{\code{opkg} upgrade over an unstable network}
+ \begin{itemize}
+ \item To avoid upgrade issues when downloading packages from a
+ remote package server using an unstable connection, you can
+ first download the packages and then proceed with the upgrade.
+ \item To do this we must use a cache, which can be defined in the
+ \code{opkg} configuration with:
+ \code{option cache /tmp/opkg-cache}.
+ \end{itemize}
+ \begin{block}{}
+ \begin{minted}{console}
+# opkg update
+# opkg --download-only upgrade
+# opkg upgrade
+ \end{minted}
+ \end{block}
+\end{frame}
More information about the training-materials-updates
mailing list