Successful packaging is a combination of automated processes performed by the OpenEmbedded build system and some specific steps you need to take. The following list describes the process:
Splitting Files:
The do_package
task splits the
files produced by the recipe into logical components.
Even software that produces a single binary might
still have debug symbols, documentation, and other
logical components that should be split out.
The do_package
task ensures
that files are split up and packaged correctly.
Running QA Checks:
The
insane
class adds a step to
the package generation process so that output quality
assurance checks are generated by the OpenEmbedded
build system.
This step performs a range of checks to be sure the
build's output is free of common problems that show
up during runtime.
For information on these checks, see the
insane
class and the
"QA Error and Warning Messages"
chapter in the Yocto Project Reference Manual.
Hand-Checking Your Packages:
After you build your software, you need to be sure
your packages are correct.
Examine the
${
WORKDIR
}/packages-split
directory and make sure files are where you expect
them to be.
If you discover problems, you can set
PACKAGES
,
FILES
,
do_install(_append)
, and so forth as
needed.
Splitting an Application into Multiple Packages: If you need to split an application into several packages, see the "Splitting an Application into Multiple Packages" section for an example.
Installing a Post-Installation Script: For an example showing how to install a post-installation script, see the "Post-Installation Scripts" section.
Marking Package Architecture:
Depending on what your recipe is building and how it
is configured, it might be important to mark the
packages produced as being specific to a particular
machine, or to mark them as not being specific to
a particular machine or architecture at all.
By default, packages produced for the target are
marked as being specific to the architecture of the
target machine because that is usually the desired
result.
However, if the recipe configures the software to be
built specific to the target machine (e.g. the
MACHINE
value is passed into the configure script or a patch
is applied only for a particular machine), then you
should mark the packages produced as being
machine-specific by adding the following to the
recipe:
PACKAGE_ARCH = "${MACHINE_ARCH}"
On the other hand, if the recipe produces packages
that do not contain anything specific to the target
machine or architecture at all (e.g. recipes
that simply package script files or configuration
files), you should use the
allarch
class to do this for you by adding this to your
recipe:
inherit allarch
Ensuring that the package architecture is correct is not critical while you are doing the first few builds of your recipe. However, it is important in order to ensure that your recipe rebuilds (or does not rebuild) appropriately in response to changes in configuration, and to ensure that you get the appropriate packages installed on the target machine, particularly if you run separate builds for more than one target machine.