Discourse… OK, third time lucky?
tl;dr: skip to the last section delimited by
# Hashing functions which
looks like the least worse idea I could come up with
(note to self:
Hmm… you’re talking about duplicating the nativeBuildInputs for every
build platform, right? If so then that’s true indeed, I hadn’t thought
about that… maybe something like  in the sandbox would solve the
issue? That said it requires changes in nix once again…
builder = [(condition, builder script)]
An alternative could be to have nix take a list of (condition, builder
script), and use the first builder script for which the condition
passes. It’s almost the same as the “derivation equivalence class” idea
you mentioned above, but avoids the problem of safety by just putting
both the cross- and the non-cross-build in the “trusted package”.
However, it still requires a way to hash the
[(cond, build)] list, but
AFAIR that can be done without ever actually fetching the dependencies,
just by computing the dependency graph of every nativeBuildInputs for
every build platform.
Pros and cons of first-class cross-compiling
Even though this may make evaluating a package slower, I must say that,
to me, this’d be a killer app of nix: afaiu, distcc and the like, though
they theoretically support cross-compiling, actually are already way too
hard to make work in non-cross-compiling setups for anyone to actually
try to use them cross-compiling.
Then, the net loss is potentially greater than the net benefit for the
average user who doesn’t cross-compile? If so, a flag “Use
cross-compile-friendly build” could make sense, that’d change the build
scripts to require a version of nativeBuildInputs for every possible
Basically, what I’m hoping is a way for RPi’s to fetch binaries from a
reasonably efficient hydra (so not from a RPi build farm ), while
still being able to locally build packages that are not on the hydra. In
order to have this, the only solution I could think of is to have the
build script be invariant of the builder.
Unfortunately, as you mention, this seems to imply at best computing the
hash of the dependency graph of all possible nativeBuildInputs (in order
to not allow an untrusted user to insert a maliciously-built package
into the store), and at worst downloading/building the nativeBuildInputs
for every possible build blatform.
But while writing this I noticed, there may be a third solution. This
third solution would be to have the builder script be parameterized by
the build platform.
However, this would require a completely reworked hashing scheme (being
able to hash a function, and not only a string), and most likely large
architectural changes in nix.
Then, current builder scripts would mean
_: "current builder script",
and there would be an easy path forwards: actually turn the builder
script into a function of the build, that would pass it to the relevant
And then, there would need to be no duplication of the depsBuildHost,
nor duplication of the computation of the dependency graph. In exchange
for hashing over functions instead of hashing over strings.
Before I raise this on the nix issue tracker, what do you think of this
idea? Is it as flawed as the previous one without my noticing?