Pub does not perform any Git operations on the cached package directly, instead cloning it through a mirror.
The .git directories are not needed, and are a source of non-determinism.
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
The dependency fixed-output derivation now uses the recursive hash mode to avoid tarballing and copying all the files.
https://github.com/NixOS/nix/issues/6660 was ran into during the development of this change. Input references were found in the Git package cache before nukeReferences was used.
It turns out that the mirrors in the Git package cache do not actually need to be preserved, as the SDK does not use them during the build process. They are therefore deleted in the dependency derivation and re-created as blank repositories in the main derivation.
A description of the Git package cache layout can be found here: c890afa1d6/lib/src/source/git.dart (L339)
Files and directories such as .dart_tool, .flutter-plugins, .packages and .pub-cache/hosted/*/.cache will be happily regenerated by the SDK in an offline environment.
The patches being made to these files and directories to remove non-determinism were flawed: They did not handle cases where files only appeared in one run, or cases where tooling versions had an effect on the output.
This brings the following benefits:
- Artifacts missing in the SDK tarball (such as prebuilts for linux-aarch64) can be obtained
- Artifacts can be patched more granularly (e.g. libflutter_linux_gtk is patchelf-ed for GTK3, and the linux-aarch64 assets have a postPatch to add some missing files)
- Minimal Flutter packages can be generated (e.g. mkFlutterApp only needs prebuilts for desktop Linux, and developers that don't care for desktop Linux can exclude the artifacts and dependencies)
It also paves the way for including manually built engine facts.
While this may be beneficial for packages that ship native binaries, this causes issues due to Flutter packages that have inappropriately uploaded build artifacts (such as those from example subprojects) to pub.dev.
Flutter 3.5.0 adds a check to make sure that the Flutter and Dart tool executables are inside the SDK directory.
This does not play nicely with the wrapping and linking techniques used to package it. It is also impossible for there to be an issue related to binary locations, as everything is set up properly in the derivation.
The internal artifacts should be used, as they have been patched to use Nix libraries.
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
Co-authored-by: gilice <gilice@proton.me>
Co-authored-by: hacker1024 <hacker1024@users.sourceforge.net>
Now that Flutter artifacts are patched, there is no need for a FHS at runtime or any stage of the build process.
Those relying on it for the Android SDK should look at https://github.com/tadfisher/android-nixpkgs.
This allows SDK artifacts (including build tools and libraries) to use the right interpreter and library locations, abolishing the need for a FHS or post-build patches.
`autoPatchelf` has been used through `autoPatchelfHook`, instead of the `autoPatchelf` command on just the artifact directory, due to the latter method not patching interpreter paths (https://discourse.nixos.org/t/trying-to-use-autopatchelf/24003).
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
Co-authored-by: gilice <gilice@proton.me>
Co-authored-by: hacker1024 <hacker1024@users.sourceforge.net>