Book Image

Embedded Linux Development Using Yocto Project - Third Edition

By : Otavio Salvador, Daiane Angolini
Book Image

Embedded Linux Development Using Yocto Project - Third Edition

By: Otavio Salvador, Daiane Angolini

Overview of this book

The Yocto Project is the industry standard for developing dependable embedded Linux projects. It stands out from other frameworks by offering time-efficient development with enhanced reliability and robustness. With Embedded Linux Development Using Yocto Project, you’ll acquire an understanding of Yocto Project tools, helping you perform different Linux-based tasks. You’ll gain a deep understanding of Poky and BitBake, explore practical use cases for building a Linux subsystem project, employ Yocto Project tools available for embedded Linux, and uncover the secrets of SDK, recipe tool, and others. This new edition is aligned with the latest long-term support release of the aforementioned technologies and introduces two new chapters, covering optimal emulation in QEMU for faster product development and best practices. By the end of this book, you’ll be well-equipped to generate and run an image for real hardware boards. You’ll gain hands-on experience in building efficient Linux systems using the Yocto Project.
Table of Contents (20 chapters)

Specifying runtime package dependencies

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

Constraints exist within multiple package relationships; however, those constraints are package format-specific, so BitBake has specific metadata to abstract those constraints.

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

  • RDEPENDS: The list of packages must be available at runtime, 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 alternative symbolic names provided by that package.
  • RCONFLICTS: This is the list of packages known to conflict with the package. The final image must not include conflicting packages.