http://bugzilla.opensuse.org/show_bug.cgi?id=1207307 http://bugzilla.opensuse.org/show_bug.cgi?id=1207307#c1 --- Comment #1 from Robert Frohl <rfrohl@suse.com> --- for completeness, TW output: $ ruby reproducer.rb checking for ruby... yes $ ruby -v ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1207307 http://bugzilla.opensuse.org/show_bug.cgi?id=1207307#c6 --- Comment #6 from Robert Frohl <rfrohl@suse.com> --- (In reply to Marcus R�ckert from comment #5)

that would be wrong. the "clean" solution would be to ship mkmf.rb in the devel package.

Could you expand on this a bit further, why this would be wrong? My thinking(from a user of the ruby library's perspective): I would expect that what is shipped as part of a package would also work and does not require me to dig into why a file is not found and also not pulled be the dependencies of the package either. Removing mkmf.rb completely from the stdlib rpm would put even more expectations on the user, to investigate the problem. From that ease of use/accessibility point of view I would think the below suggestion is a good middle ground. (In reply to Robert Frohl from comment #4)

How about just shipping a additional copy of ruby.h in /usr/lib64/ruby/include with the ruby<version> package?

ok, looked a bit further and think the above is actually wrong, as mkmf.rb comes from another package (ruby<version>-stdlib). The suggestion actually would be to ship ruby.h with ruby<version>-stdlib instead. -- You are receiving this mail because: You are on the CC list for the bug.