ansible-11.1.0-2.fc42.noarch
  modified-....N...... /usr/lib/python3.13/site-packages/ansible_collections/amazon/aws/requirements.txt
  modified-....N...... /usr/lib/python3.13/site-packages/ansible_collections/ansible/utils/bindep.txt
  modified-....N...... /usr/lib/python3.13/site-packages/ansible_collections/ansible/utils/cspell.config.yaml
  modified-....N...... /usr/lib/python3.13/site-packages/ansible_collections/ansible/utils/meta/runtime.yml
...

N is shown because the hardlink counts differ. In the rebuild, more identical files are hardlinked. In the original build, various files that could be hardlinked, are not hardlinked, and when we actually hardlink them successfully, we end up with a difference in the rebuild.

My understanding is the following:

• During %install, all files are copied, and the mtime is reset.
• When hardlink runs, it checks if mtime is identical, so it only hardlinks some of the files which are otherwise identical.
• Rpm clamps mtimes of files, but that happens later. So during %install, when the spec invokes hardlink, we see some mtimes that depend on copying speed and possibly filesystem timestamp precision, but then in the final rpm those mtimes are are clamped to the same value.
• In effect, we end up with an irreproducibility based on the system speed, file system type, and races during file copying.

ansible uses [1] standard %pyproject_wheel and %pyproject_install macros. It seems that either those macros or the underlying tooling resets mtimes. Packaging guidelines specify that mtimes of unmodified files should be preserved. It seems we want to fix that. That will resolve the apparent irreproducibility too.

[1] https://src.fedoraproject.org/rpms/ansible/blob/rawhide/f/ansible.spec#_129