Change:
Relevant snippet while building it fails with I copied over the for debugging, this is the full output: Steps to reproduce the behavior: snippet as flake default output Build should succeed and images should be loadable via Patching the as follows: fixes the problem, but would probably hide other cp errors. Maybe the behavior of coreutils/cp changed in the recent versions. At least the current manual states it will fail silently. I'm using a linux-builder on my machine.
Thank you for reporting this. I’ll try to replicate this locally. The lines do not look like errors to me. It looks like is informing that those files already exist in the output and thus are skipped (--no-clobber). However, if the build is failing there’s something going wrong.
Thank you for linking the manual. It looks like will exit with a non-zero status code in case of files that are already present now. The coreutils changelog states that now reproduces the behavior had at the time I wrote the mergeImages script. I was able to build by changing to . I don't know how to best go about obtaining the behavior everywhere, should the flag be dependent on the version of somehow? Maybe we can just assume that in will be a new version from now so that we can use everywhere? Given that all files that are present in both docker images apart from the and repositories files should be content addressed the only issue with removing is that time is spent unnecessarily writing content that's already present, so removing the flag altogether might make sense.
Thanks for investigating! I'm not familiar with the backward compatibility policy of the nix ecosystem, but I would assume that the most recent version of can assume most recent coreutils. Might happen that someone is overlaying old coreutils but then you might just need to overlay the old too, if you can pinpoint it down to coreutils cp.
True, but then apparently they have a legacy software problem, in which case they should use overrides only where it is necessary, instead of a blanket override in an overlay. It is not realistic to expect all of Nixpkgs to work with arbitrary changes. The cost of such compat logic isn't worth it; certainly not in this case, until proven otherwise. If they contribute a full time maintainer it is worth it, and if they have a legacy software problem they probably can.

Discussion:
, closureInfo , coreutils , e2fsprogs <del> , fakechroot </del> <ins> , proot </ins> , fakeNss , fakeroot , go

fi done # Copy all layers from input images to output image directory <del> cp -R --no-clobber inputs/*/* image/ </del> <ins> cp -R --update=none inputs/*/* image/ </ins> # Merge repositories objects and manifests jq -s add "''${repos[@]}" > repositories jq -s add "''${manifests[@]}" > manifest.json

}); contentsList = if builtins.isList contents then contents else [ contents ]; <ins> bind-paths = builtins.toString (builtins.map (path: "--bind=${path}:${path}!") [ "/dev/" "/proc/" "/sys/" "${builtins.storeDir}/" "$out/layer.tar" ]); </ins> # We store the customisation layer as a tarball, to make sure that # things like permissions set on 'extraCommands' are not overridden

nativeBuildInputs = [ fakeroot ] ++ optionals enableFakechroot [ <del> fakechroot # for chroot coreutils # fakechroot needs getopt, which is provided by util-linux util-linux </del> <ins> proot </ins> ]; postBuild = '' mv $out old_out (cd old_out; eval "$extraCommands" ) mkdir $out <del> ${optionalString enableFakechroot '' export FAKECHROOT_EXCLUDE_PATH=/dev:/proc:/sys:${builtins.storeDir}:$out/layer.tar ''} ${optionalString enableFakechroot ''fakechroot chroot $PWD/old_out ''}fakeroot bash -c ' </del> <ins> ${optionalString enableFakechroot ''proot -r $PWD/old_out ${bind-paths} --pwd=/ ''}fakeroot bash -c ' </ins> source $stdenv/setup ${optionalString (!enableFakechroot) ''cd old_out''} eval "$fakeRootCommands"