▲ | BobbyTables2 4 days ago | |||||||
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_ 4 days ago | parent | next [-] | |||||||
> 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 4 days ago | parent | prev [-] | |||||||
> 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. | ||||||||
|