Should ruby-build fix Ruby 3.0 by patching it on macOS?

[mislav]

We're getting a lot of support requests for Ruby 3.0 failing on macOS 14+ due to a known bug in bigdecimal.c that's been fixed in Ruby 3.1 but won't get backported to 3.0 #2185 (comment)

The solution we give users is always the same: apply an upstream patch.

My question is: to reduce our workload and give users a better experience, should ruby-build automatically apply this patch to Ruby 3.0 to enable it to compile on macOS? This is perhaps controversial because ruby-build had historically always refused to apply any patches automatically, guaranteeing that you're always running a "vanilla" version of Ruby, and because Ruby 3.0 is EOL and it shouldn't be anyone's business to help EOL versions compile. But here we are.

Alternative solutions:

• In BUILD FAILED messages there could be a textual hint about this patch, if the compilation errored out in bigdecimal.c
• Do nothing and let people figure it out on our discussion forums

Thoughts @hsbt @eregon?

[hsbt]

I'm negative to add patch to our definition.

This is perhaps controversial because ruby-build had historically always refused to apply any patches automatically, guaranteeing that you're always running a "vanilla" version of Ruby

Agreed.

In BUILD FAILED messages there could be a textual hint about this patch, if the compilation errored out in bigdecimal.c

I prefer that. or We can add that workaround to FAQ section with https://github.com/rbenv/ruby-build/wiki#troubleshooting?

[eregon]

I think adding some extra text in the output sounds helpful, e.g. linking to #2185 (comment), agreed we shouldn't automatically patch that.

The fact OpenSSL 1.1 is EOL and Ruby 3.0 doesn't support OpenSSL 3 is another reason nobody should use Ruby 3.0 these days.

[eregon]

I think for simplicity it'd be fine to just output some early text linking to that solution whenever installing 3.0.x, e.g. just adding some echo's in the definitions.