Why is --impure required for building a nix-on-droid configuration from a flake?

[shelvacu]

I noticed the nix-on-droid script adds --impure if given a flake uri, and if I try to build manually without --impure it doesn't work:

# nix build .#nixOnDroidConfigurations.default.activationPackage
trace: warning: The type `types.string` is deprecated. See https://github.com/NixOS/nixpkgs/pull/66346 for better alternative types.
error:
       … while calling the 'derivationStrict' builtin

         at /builtin/derivation.nix:9:12: (source not available)

       … while evaluating derivation 'nix-on-droid-generation'
         whose name attribute is located at /nix/store/lr42p9vxg420i8yfqadqp1w9wxdmdci2-source/pkgs/stdenv/generic/make-derivation.nix:348:7

       … while evaluating attribute 'buildCommand' of derivation 'nix-on-droid-generation'

         at /nix/store/lr42p9vxg420i8yfqadqp1w9wxdmdci2-source/pkgs/build-support/trivial-builders/default.nix:87:14:

           86|       enableParallelBuilding = true;
           87|       inherit buildCommand name;
             |              ^
           88|       passAsFile = [ "buildCommand" ]

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: 'builtins.storePath' is not allowed in pure evaluation mode

       at «none»:0: (source not available)

Why is builtins.storePath needed? Normally I'd just look at the code but, builtins.storePath is never used??

[shelvacu]

--show-trace will lie to you. In modules/environment/login/default.nix there is a bare string "/nix/store/yrrs22jsl1y8niwzs2vvk0vblicr3903-proot-termux-static-aarch64-unknown-linux-android-unstable-2023-05-13" which then gets placed in a shell script in one of the outputs, which through some nix magic I don't quite understand means it tries to add that as a dependency, which super-internally calls builtins.storePath. --show-trace will lie to you. But why is it a bare string? Why not just have prootStatic = pkgs.prootTermux;, after all the package is already in the repo and you can even build it. For some reason I fnorded the relevant section in the readme until today:

Note: The proot binary is not built on the android device (NDK is required for building it, and it's not available on mobile platforms). The way we work around it is to push proot derivation to cachix. The current workaround is to hardcode the path to the wanted proot nix store path in modules/environment/login/default.nix. During evaluation time on the android device this store path will be downloaded from the binary cache (https://nix-on-droid.cachix.org/). This in return means the proot derivation has to be present there or in any other binary cache configured in the nix.conf on the device.

If I understand this correctly (--show-trace will lie to me), this is saying that to build the proot-static binary you need a system which can run both x86_64-linux and aarch64-linux (this is achieved with binfmt+qemu magic on an x86 system). Since your android phone cannot run x86_64 binaries, it cannot build proot-static.

"But wait!" I hear you say. "The android phone doesn't need to build proot-static. It already comes configured with the nix-on-droid cachix substituter. All is well! --show-trace would never lie to me!"

And you'd be right, except that nix will make sure it can build everything regardless of whether closures can be obtained from a substituter. This means that because your android phone can't build proot-static in theory, it won't attempt to build-or-grab it in practice and instead just error. And also --show-trace is always lying to you.

[t184256]

If I understand this correctly (--show-trace will lie to me), this is saying that to build the proot-static binary you need a system which can run both x86_64-linux and aarch64-linux (this is achieved with binfmt+qemu magic on an x86 system). Since your android phone cannot run x86_64 binaries, it cannot build proot-static.

This is not true.

To build a proot-static (and the entirety of bootstrap zipball), you only need Android SDK toolchain and a x86_64-linux host. No aarch64-linux building capabilities are required.

I've made several attempts to build an identical proot using either x86_64-linux or aarch64-linux using a non-precompiled toolchain. I was not successful.