[BobbyTables2]

Did Yocto ever clean up how they manage the sysroot?

It used to have a really bad design flaw. Example: - building package X explicitly depends on A to be in the sysroot - building package Y explicitly depends on B in the sysroot, but implicitly will use A if present (thanks autoconf!)

In such a situation, building X before Y will result in Y effectively using A&B — perhaps enabling unintended features. Building Y then X would produce a different Y.

Coupled with the parallel build environment, it’s a recipe for highly non deterministic binaries — without even considering reproducibility.

[adev_]

> Did Yocto ever clean up how they manage the sysroot?

It's better than before but you still need to sandbox manually if you want good reproducibility.

Honestly, for reproducibility alone. There is better than Yocto nowadays. It is hard to beat Nix at this game. Even Bazel based build flows are somewhat better.

But in the embedded world, Yocto is pretty widespread and almost the de-facto norm for Linux embedded.

[1718627440]

> but implicitly will use A if present (thanks autoconf!)

When you want reproducibility, you need to specify what you want, not let the computer guess. Why can't you use Y/configure --without-A ? In the extreme case you can also version config.status.

[BobbyTables2]

One certainly can, but such is not default.

Things using autotools evolved to be “manual user friendly” in the sense that application features are automatically enabled based on auto detected libraries.

But for automated builds, all those smarts get in the way when the build environment is subject to variation.

In theory, the Yocto recipe will fully specify the application configuration regardless of how the environment varies…

Of course, in theory the most Byzantine build process will always function correctly too!