[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