At the moment, delocate-fuse doesn't check and just keeps one of the two files. For reproducible builds this is fine, but if you have for example a generated header file which depends on the architecture (e.g., contains size of long double, a real bug we had in numpy), there is a problem. There are a few possible merge strategies possible:
error out
pick one file at random
pick the files from the first wheel that was fed to delocate-fuse
The safest bet would be to error out, and allow users to specify a list of files that are known to differ between x86-64 and arm64, with the specification of which to pick. This is likely to catch some bugs, and improve the reproducibility of wheel builds.
In https://github.com/pypackaging-native/pypackaging-native/pull/27#discussion_r1142744075, @freakboy3742 pointed out a potential problem with
delocate-fuse: when two files (.py,.h, or any other file type other than the binaries that actually need fusing) differ, it is unclear what to do.At the moment,
delocate-fusedoesn't check and just keeps one of the two files. For reproducible builds this is fine, but if you have for example a generated header file which depends on the architecture (e.g., contains size oflong double, a real bug we had innumpy), there is a problem. There are a few possible merge strategies possible:delocate-fuseThe safest bet would be to error out, and allow users to specify a list of files that are known to differ between x86-64 and arm64, with the specification of which to pick. This is likely to catch some bugs, and improve the reproducibility of wheel builds.