Chapter 6. Assimilating Packaging Support

This chapter presents the key concepts for understanding the aspectsofPoky and BitBake related to packaging. We will learn about the supported binary package formats, shared state cache, package versioning components, how to set up and use binarypackage feedsto support our development process, and more.

Using supported package formats

Packages are critical to Poky as they enable the build system to produce different types of artifacts, such as images and toolchains.

A recipe may generate one or more packages as a result of it being executed by BitBake. On the other hand, images and toolchains are made of several packages that are unpacked and configured to accomplish the intended goal. The generated result is wrapped in such a way that it can be installed into one or more images, or it can be deployed for later use.

List of supported package formats

Currently, BitBake supports four different package formats:

• RPM: Originally named Red Hat Package Manager (RPM), but now known as the RPM package format since its adoption by several other Linux distributions, it is used by popular Linux distributions such as SuSE, OpenSuSE, Red Hat, Fedora, and CentOS, among others.
• DEB: The Debian Package Manager is used by Debian and several other Debian-based distributions; the most widely known among them are...

Understanding shared state cache

The default behavior of Poky is to build everything from scratch unless BitBake determines that a recipe does not need to be rebuilt. The main advantage of building everything from scratch is that the final result is fresh and there is no risk of previous data causing problems. However, rebuilding everything requires computational time and resources.

The strategy to determine whether a recipe must be rebuilt is complex. Basically, BitBake tries to track as much information as possible about every task, variable, and code used in the build process. BitBake then generates a checksum for all the involved information for every task.

Poky uses all this information provided by BitBake to store snapshots of those tasks as a set of packaged data generated in a cache, which is called the shared state cache (sstate-cache). This cache wraps the contents of each task output in packages stored in the SSTATE_DIR directory. Whenever BitBake prepares to run a task, it first...

Explaining package versioning

Package versioning is used to differentiate the same package in different stages of its life cycle. From Poky's perspective, it is also used as part of the equation that generates the checksum used by BitBake to verify whether a task must be rebuilt.

The package version, also known as PV, plays a central role when we select which recipe to build. The default behavior of Poky is to always prefer the newest recipe version, unless there is an explicit different preference, as we discussed in the Chapter 4, Grasping the BitBake Tool. For example, consider that we have two versions of the recipe myrecipe—myrecipe_1.0.bb and myrecipe_1.1.bb. BitBake, by default, builds the recipe with version 1.1.

Inside the recipe, we may have other variables that compose package versioning with the PV variable. These are package epoch, known as PE and package revision, known as PR.

The PE variable has a default value of zero and is used when the package version schema is changed, breaking...

Specifying runtime package dependencies

The end results of most recipes are packages that are managed by the package manager. As we saw in the previous sections, it requires information about all those packages and how they relate to each other. For example, a package may depend on or conflict with another.

There are multiple package constraints that need to be expressed; however, those constraints are package format-specific, so BitBake has a specific metadata set used to abstract those package constraints.

Here is a list of the most commonly used runtime constraints:

• RDEPENDS: This is the list of packages that are required to be installed along with the package that defines it.
• RPROVIDES: This is the list of symbolic names a package provides. By default, a package always includes the package name as a symbolic name. It can also include other symbolic names alternatively provided by that package.
• RCONFLICTS: This is the list of packages that are known to conflict with this package. Only one...

Package feeds

As we discussed in Chapter 4, Grasping the BitBake Tool, packages play a central role, as images and SDKs rely on them. In fact, do_rootfs makes use of a local package repository to fetch the binary packages when generating the root filesystem. This repository is generally known as a package feed.

There is no reason for this repository to be used just for the images or SDK build steps. In fact, there are several valid reasons for making this repository remotely accessible internally in our development environment or publicly for use in the field. Some of these reasons are listed, including the following:

• Easily testing an updated application during development stage, without the need of a complete system re-installation
• Make additional packages more flexible so that they can be installed in a running image
• Update products in the field

To produce a solid package feed, we must ensure that we have consistent increments in the package revision every time the package is changed. It is...

Summary

This chapter presented the basic concept of packaging, a concept that has a central role for Poky and BitBake; package versioning; and how this impacts Poky's behavior when rebuilding packages and package feeds. It also showed us how to configure an image to be updated using prebuilt packages provided by a remote server.

In the next chapter, we will learn about the BitBake metadata syntax and its operators to append, prepend, and remove content from variables, variable expansions, and so on. We will then be able to understand the language used in Yocto Project engines better.