文档章节

The Packaging Process in Yocto/OE

ChenQi
 ChenQi
发布于 2013/11/04 17:36
字数 1079
阅读 213
收藏 0

The automatic packaging process in Yocto (updating with latest Yocto/OE)
========================================================================

Basics about Yocto [important]
------------------------------
The Yocto project ulitizes bitbake (a metadata interpreter and task scheduler)
and meta data from OE to automakes the the process of building a customized
Linux distro.

If you've built out a running Linux, you probably know the basic process of
doing so. Take LFS (Linux From Scratch) as an example, it first builds out a
toolchain; the toolchain is then used to build out the real root file system.
The basic steps of building a package and install it into the rootfs mainly
involves the following steps in LFS:
1. get the source package and needed patches
2. unpack the compressed source tarball
3. patch the source code
4. configure the source code
5. compile the source code
6. install the generated files into the root file system

With the above working flow, we can build out a Linux. However, it still has
several shortcomings.

First and most important, it lacks automation.
Repeating the 'configure, make, make install' process for hundreds of packages
is not only boring but also error prone. The above six steps are really common
for all packages, there's no reason why we can't automate this process.

Second, it lacks package management.
While this is OK for small systems with only a few packages, it would really be
a disaster for large systems with hundreds of packages. The importance of
package management is so obvious that I will not detail the reason here.

Of course there are other shortcomings such as cross compilation complexity. I'm
not going to detail them here because this document mainly focuses on packaging
automation in Yocto.

Let's look at how Yocto solves the above two problem.

Before that, let's look at some basic tasks in Yocto for building a package.
1. do_fetch
2. do_unpack
3. do_patch
4. do_configure
5. do_compile
6. do_install
7. do_package
There are other tasks, but the above seven are the most important ones. The
first six tasks corresponds to the six common steps in LFS, the last task is
used to support package management.

Now, let's answer the question of how Yocto supports automation of building out
a package. As stated above, the Yocto project comprises two components, bitbake
and metadata. In brief, bitbake reads and interprets metadata into tasks,
resolves dependencies among tasks and runs each task in proper order. Tasks like
do_configure are written as metadata in classes or recipes. Task dependencies
are also encoded in classes or recipes. In this way, people could reuse others'
work. Normally, users may not even need to look into the recipes.

Yocto supports three kinds of package backend, that is, rpm, ipk and deb. This
document only discusses rpm package management support in Yocto, as the rest two
are totally analogous.

To make package management work in Yocto, two things are essential. One is to
build out rpm packages and the other is to make the database generated at
rootfs time usable on target. Note that we're building packages and installing
them into the target root file system on our build machine, so we have to be
careful that when installing packages, the generated database could still be
used on target. Please refer to package_rpm.bbclass, rootfs_rpm.bbclass to see
how we make this work. One might argue that a package management tool is also
essential. Absolutely correct. But it's just a matter of installing the tool
into rootfs. Nothing complex. How to build out rpm packages is a more complex
task and this document endeadors to expain it clearly.


Basics about packaging [important]
----------------------------------
I'll firt give out a brief overview of the packaging process in Yocto, then I'll
explain the technical details in format of 'Q & A'.

We have to first make clear the inputs and outputs of the packaging process.
Input: the output of do_install task in ${D}
Output: splited rpm packages in ${DEPLOY_DIR}

The process of packaging is as follows:

1) do_package
   Input is ${D}, output is ${PKGDEST}.
   D = ${WORKDIR}/image
   PKGD = ${WORKDIR}/package
   PKGDEST = ${WORKDIR}/packages-split

   *) set up PKGD (from D)
      *) perform_pkgcopy
      *) ${PACKAGE_PREPROCESS_FUNCS}
      *) split_and_strip_files
      *) fixup_perms
   *) split PKGD into PKGDEST
      *) pacakge_do_split_locales
      *) populate_packages
   *) process PKGDEST
      *) package_fixsymlinks
      *) package_name_hook
      *) package_do_filedeps
      *) package_do_shlibs
      *) package_do_pkgconfig
      *) read_shlibdeps
      *) package_depchains
      *) emit_pkgdata

2) do_packagedata
   -- dummy task to mark when dealing with package data is complete

3) do_package_write_rpm
   *) read_subpackage_metadata
      PKGDATA_DIR = ${WORKDIR}/pkgdata
      This task gets information from ${PKGDATA_DIR}/runtime/pkg and set
      corresponding variables.
      The ${PKGDATA_DIR}/runtime/pkg file is created in the do_package task by
      the emit_pkgdata function.
   *) do_package_rpm
      *) write spec file
      *) build .src.rpm packages if necessary
      *) build rpm packages

4) do_package_write
   -- dummy task to mark when all packaging is complete
   -- do_package_write[noexec] = "1"

Q1: As we can see, the ${PKGD} is actually an intermediate directory which is
    basically a copy of ${D}. So why do we need this directory?

    We need this directory because we should not change the contents in the ${D}
    directory in the packaging process. In this way, the packaging process is
    seperated from the installing process. We can safely rerun the packaging
    tasks without re-executing the do_install task.

Q2. Why do we need the pkgdata files (${WORKDIR}/pkgdata/*)?

    We need these files to store information about packages so that the
    do_package_write_rpm task is seperated from the do_package task, or the
    do_packagedata task is seperated from the do_write_package task. This
    ensures we don't have unnecessary reruns of those tasks in the do_package
    period.



Relavent Classes [important]
----------------------------
package.bbclass
package_rpm.bbclass
packagedata.bbclass
prserv.bbclass


Other Questions and Answers [important]
1. Why is rpm-native needed for every package backend?
   In package.bbclass, the comment states that rpm-native is needed for per-file
   dependency identification. What does it mean? Also, why is file-native needed
   for every package backend?

   rpm-native is needed for per-file dependency identification which is
   performed by the `package_do_filedeps' function. It's also needed by the
   `split_and_strip_files' function which uses debugedit from rpm-native.
   file-native is needed for the stripping process to work correctly.

2. Why the do_packagedata task of each DEPENDS must have completed before the
   do_package task starts?
   d.appendVarFlag('do_package', 'deptask', " do_packagedata")
   (do_package[deptask] = "do_packagedata")
   For example, if the `findutils' depends on `autoconf-native', so the
   do_packagedata task of autoconf-native must have completed before the package
   task for findutils to start.

   shlibs requires any DEPENDS to have already packaged for the *.list files

3. What is the configure.sstate file under ${WORKDIR} used for?
   meta/classes/autotools.bbclass:
   CONFIGURESTAMPFILE = "${WORKDIR}/configure.sstate"
   This value is compared with the BB_TASKHASH value to determine whether the
   build directory needs to be cleaned up.

© 著作权归作者所有

ChenQi
粉丝 61
博文 191
码字总数 111579
作品 0
丰台
高级程序员
私信 提问
shell脚本解析 -- oe-init-build-env

oe-init-build-env #!/usr/shif [ -z "$ZSH_NAME" ] && [ "x$0" = "x./oe-init-build-env" ]; thenecho "Error: This script needs to be sourced. Please run as '. ./oe-init-build-env'"e......

ChenQi
2012/08/05
2.5K
0
OpenEmbedded Yocto 笔记

http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html 参考手册 http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html 开发手册 http://elinux.org/BitbakeC......

3444542
2013/07/29
0
0
手动创建一个recipe

执行一个recipe。 调用#bitbake basename来执行一个recipe。其中包括:解压缩源代码包、log文件以及编译过程中的中间文件等。 在每个recipe中定义temporary工作目录,具体定义如下: BASE_W...

linuxhunter
2016/08/22
624
0
构建mips64el架构下的目标系统,MACHINE配置为qemumips64后,配置内核小端模式失败?

构建mips64el架构下的目标系统,MACHINE配置为qemumips64后,配置内核小端模式;命令如下: bitbake -c menuconfig virtual/kernel 配置完成后,开始构建目标系统, bitbake core-image-min...

dannimama
06/20
14
0
Yocto 1.1 版本发布,嵌入式应用开发协作系统

10月26日下午,来自LinuxCon 欧洲大会的消息,Yocto 1.1版本发布,并引入大量新特性。 Yocto Project™ 是一个开源的协作软件,提供模板、工具和方法帮你创建定制的 Linux 系统和嵌入式产品,...

小卒过河
2011/10/26
1K
0

没有更多内容

加载失败,请刷新页面

加载更多

对于初学者怎么学好画画?

怎样才能学好绘画?想学好绘画需求做什么?光影怎么运用?学习绘画难吗?便是不知道怎么才能绘画好自己作品的光影! 先灵魂起稿画一个大概 在根据前面几何体的理解运用在练习上 假设一个顶光...

热爱画画的我
11分钟前
2
0
Android studio初次安装启动时弹出unable to access android sdk add-on list提示的解决方法

一、问题描述 初次安装Android Studio,启动后,报错如下: unable to access android sdk add-on lis 如图: 二、原因分析 AS启动后,会在默认路径下检测是否有Android SDK,如果没有的话,...

风君子博客
25分钟前
1
0
程序员面试,为什么不跟我谈高并发?

作为一个看过几千份简历,面试过几百人的面试官,常常会看到简历中有如下文字: 对业务逻辑解耦,高并发等有比较深入的研究和丰富的开发实战经验 对解决高并发问题有深入理解 熟悉大并发技术...

程序员修BUG
29分钟前
4
0
Java中UUID版本5使用

问题 生成UUID版本5作为唯一ID。某些场景不能依赖数据库来生成唯一ID,就需要使用UUID来生成唯一性ID。 解决 Java private static final String NAMESPACE_URL = "6ba7b811-9dad-11d1-80b4...

亚林瓜子
29分钟前
5
0
js 设置焦点 判断控件是否获得焦点 判断哪个控件获得焦点

<html> <head> <title>设置焦点</title> <mce:script language ="javascript"> <!-- function init(){ var ctrl=document.getElementById("UserName"); ctrl.focus(); } // --> </mce:scrip......

前端老手
31分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部