Based on the official manual, I was under the impression that ofborg respected the setting of meta.platforms. However, I’m currently seeing a situation in which meta.platforms does not include aarch64-linux, but ofborg is still trying (and failing) to evaluate the package on aarch64-linux.
Why is ofborg not respect the setting of meta.platforms? What does one have to do in order to prevent ofborg from getting hung up on unsupported platforms?
Well, nix-env -qa shouldn’t bail on any platform. Typically you avoid reaching any bad parts by some combination of assert/throw/meta.broken/…
EDIT: but it’s still possible that there’s some unnecessary strictness, either in ofBorg or triggered by it (e.g. somewhere in stdenv). I just had a quick glance on what you linked.
I’m not aware of a mechanism, but I don’t manipulate it a lot.
In any case, I imagine eval failures are a bigger problem than build failures (my mental model suspects that meta.platforms / broken will exempt you from actual builds, but not from eval checks).
Maybe ofborg maintainers such as @cole-h@Artturin@andir know if there’s a lever and if this is a situation that merits pulling it.
it feels correct to me that even if some platform isn’t supported then it still should not fail with a “attribute missing” on that platform with NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1
src = if !cudaSupport then (cpuSrcs."${stdenv.hostPlatform.system}" or (throw "jaxlib not supported on ${stdenv.hostPlatform.system}")) else gpuSrc;
Missing attribute is a hard error, e.g. like abort. Errors like from throw are catchable and e.g. nix-env -qa will just skip such packages (maybe with printing some warning).