Yocto is a powerful toolkit for building custom embedded Linux distributions, but its flexibility can become a maintenance burden when the project does not require deep customization. This article explains when Yocto makes sense, the hidden costs of a custom distro, and why an established distribution such as Debian, combined with tools like mkosi, ELBE or debos, can be a more efficient choice for many embedded projects.

You probably don’t need Yocto, and that’s fine

Why Yocto is the default answer

When a new embedded Linux project starts, many customers assume that a "serious" solution must be built with Yocto. The Yocto Project provides a complete toolchain—bitbake, openembedded-core, and the reference distribution Poky—that lets you assemble a Linux system from source, apply arbitrary patches, and pin every component to an exact version. On top of that, most SoC vendors ship Board Support Package (BSP) layers that give you a ready‑made starting point. The combination of fine‑grained control and vendor support makes Yocto an attractive default.

The hidden responsibility of a custom distro

Regulations such as the Cyber Resilience Act (CRA) require product vendors to keep shipped software secure for the entire product lifetime. A Yocto release is typically supported for seven months; only the LTS releases (e.g., Yocto 5.0 Scarthgap) receive up to four years of updates. Those updates consist of back‑ported bug fixes and security patches applied to the set of recipes that define the distribution.

If you have applied non‑trivial patches, added extra components, or pinned versions to achieve a particular fix, each new Yocto maintenance release forces you to verify that your changes still apply cleanly. Moreover, any extra packages you introduced are invisible to the Yocto maintainers, so you must track their security updates yourself. In practice, the maintenance effort ends up being yours, regardless of whether you use Yocto or not.

The kernel illustrates the point. Yocto ships a kernel, but most projects need vendor‑specific patches and a newer kernel than the one bundled in Poky. Maintaining an up‑to‑date kernel therefore becomes a separate task, whether you use Yocto or not. A pragmatic approach is to base the kernel on an LTS release from kernel.org, keep all modifications in a tidy patch queue, and re‑apply that queue whenever a new stable kernel appears. The same philosophy can be applied to the bootloader, which is often vendor‑specific and rarely receives timely security updates.

The real cost of building your own distribution

Aspect	Yocto impact
Build time	Compiling everything from source can take hours on a fast workstation. Incremental builds rely on a fragile sstate cache; a small recipe change may invalidate large portions of it.
Disk & CI resources	A full Yocto build directory easily exceeds 100 GiB. Continuous‑integration runners need ample storage and a strategy for sharing the sstate and DL_DIR caches.
Learning curve	Engineers must master bitbake syntax, layer architecture, class inheritance, overrides, and the distinction between DEPENDS and RDEPENDS. Onboarding typically takes weeks.
BSP quality	Vendor layers vary widely; some are clean and well‑maintained, others pin outdated kernels, mix machine‑specific recipes into the wrong layers, and break when Poky is upgraded.

These factors translate into real engineering effort that could otherwise be spent on product features.

When an established distribution is sufficient

If the goal is simply to run an application on a modern Linux base, a mature distribution such as Debian GNU/Linux can satisfy most requirements with far less per‑project work. Debian provides roughly 70 000 binary packages for a wide range of architectures (amd64, arm64, armhf, riscv64, ppc64el, …). In many cases the target SoC can execute those binaries directly, eliminating the need for recompilation.

Debian’s maintenance model

Security updates – The Debian Security Team supplies fixes for the stable release for about three years. After that, the community‑run Debian LTS project extends support for roughly two additional years, giving a total of five years of maintenance—comparable to Yocto LTS but without the need to back‑port patches yourself.
Image creation – Tools such as mkosi, ELBE, and debos can generate deterministic, flashable images that combine a vendor‑specific bootloader, a kernel built as a Debian package, and a root filesystem sourced from Debian archives. The workflow resembles the classic apt update model: pulling newer packages and re‑building the image.

A concrete debos workflow

Run a local Debian mirror with aptly to host the exact set of packages required for the product.
Build the kernel and, optionally, the bootloader as Debian packages and add them to the mirror.
Snapshot the mirror and tag the snapshot as a release.
Write a debos YAML recipe that installs the needed packages, runs any custom commands, and assembles the final flashable image.
Optionally generate an SBOM with debsbom to satisfy GPL source‑availability and CRA bill‑of‑materials requirements.

Because the bulk of the system comes from Debian, most updates are a simple apt refresh rather than a rewrite of bitbake recipes.

Decision matrix: Yocto or not?

Use Yocto when	Skip Yocto when
You need deep customisation of the user space, compile flags, or base components.	You only need a modern Linux environment to run your application.
Size or boot‑time constraints cannot be met by an off‑the‑shelf distro.	Your device has enough flash (hundreds of MB) and RAM (≥256 MiB) for a standard Debian image.
License restrictions forbid GPLv3 components; Yocto’s `INCOMPATIBLE_LICENSE` mechanism helps enforce this.	You prefer to rely on Debian’s security team rather than maintain a custom patch set.
The vendor’s official support path is Yocto and the BSP layer is high quality.
	You need to rebuild many Debian packages, effectively recreating the work that Yocto’s recipe system already handles.
	You require a non‑glibc C library (musl, uClibc); Debian’s archive is built around glibc.
	You need very recent toolchains or runtimes that are unavailable in Debian stable.

The key is to make the choice early, because changing the base system after a product ships is costly.

Conclusion

Yocto is an impressive engineering achievement that gives you the power to craft a Linux distribution that matches your hardware and functional requirements exactly. That power, however, becomes a liability when the project does not demand such precision. The maintenance obligations imposed by regulations like the CRA mean that every custom distribution carries a hidden cost: you own the updates.

For the majority of embedded projects, an established distribution such as Debian, combined with deterministic image builders like mkosi, ELBE, or debos, provides a secure, well‑maintained foundation with a fraction of the engineering overhead. When you truly need surgical control over the system—tight size limits, unusual licensing, or a vendor‑mandated Yocto BSP—then Yocto (or a similar build‑from‑source tool like Buildroot) is the right answer.

In practice, ask the question early: Do we really need to build our own distribution? If the answer is no, you can avoid years of hidden maintenance work and focus on delivering value to your customers.

References