Thanks for the reply! I'm sorry -- this pull request #note-1 currently fails CI, and I'm still investigating why. It's not ready for review yet, so it would be appreciated if you could revisit when it is.
Could you clarify what you mean by "distributions/package-managers"? Also, do they actually include the RubyGems log files (like mkmf.log) in their packages?
Could you clarify what you mean by "distributions/package-managers"?
"distributions/package-managers" in the issue description refers, broadly, to systems that allow software packages to cooperate -- automatically tracking dependencies, locating files, and managing environment variables -- while making them easily installable, upgradable, and removable. Here, however, I specifically mean systems with stricter reproducibility guarantees, such as the Guix or Nix package managers.
For those unfamiliar with such systems, these are conceptually similar to Bundler. For example, running guix shell ruby ruby-nokogiri drops you into a shell with Ruby and Nokogiri installed and the environment fully set up. The key difference is that these guarantee that installing the same package on the same architecture always produces bit-for-bit identical results.
Also, do they actually include the RubyGems log files (like mkmf.log) in their packages?
Yes, at least with Guix, some packages do include the log files.
That said, as these files are increasingly being identified as a source of reproducibility check failures, existing packages may also start applying workarounds in their recipes, such as explicitly deleting these log files.
As I described in the issue, based on my research into the history of this topic, I had assumed that including log files such as mkmf.log in the files generated by gem install was intended behavior. That said, if gem install were changed to skip these files, I would consider that a step in the right direction (for reproducibility-aware package managers).
I agree with @nobu (Nobuyoshi Nakada) that these files are not meant to be installed, so I would like to fix this on the installation side rather than by making mkmf output deterministic.
There are two paths:
For gem install, RubyGems should stop placing the build logs in the installed extension directory. This is tracked at https://github.com/ruby/rubygems/issues/6259, and I will open a pull request for it later.
For the gems bundled with Ruby, the artifacts leak through rbinstall, so I opened https://github.com/ruby/ruby/pull/17578 to drop the in-tree build leftovers such as mkmf.log, Makefile and object files from the installed gem directory. The compiled extension is installed separately, so removing them is safe.
Together these should resolve the reproducibility problem you described.
[Bug #21995] Exclude C extension build artifacts from installed bundled gems
Bundled gem extensions are built in place under .bundle/gems, which
leaves mkmf.log, Makefile, object files and the in-tree shared library
behind. UnpackedGem#collect then packs them into the installed gem
directory, where they are non-reproducible and unused at run time. This
breaks bit-for-bit reproducibility for distributions like Guix and Nix.
Filter them out at collection so only sources ship.
Updated by 
Updated by 
Updated by 
Updated by