Replies: 1 comment 2 replies
-
I think new archives with the openssl major+minor numbers as you showed would be best indeed. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Currently Windows Rubies 2.5 thru 3.1 use OpenSSL 1.1.1. The current MSYS2 package is also OpenSSL 1.1.1.
The RubyInstaller2 Ruby 3.2 is built with a custom OpenSSL 3.0.x package. Also, I suspect sometime this year, the MSYS2 OpenSSL package will be updated to 3.0.x.
Windows Rubies earlier than 2.5 use custom OpenSSL packages, and the only way to easily use them is by using setup-ruby-pkgs.
For Actions, setup-msys2-gcc runs cron jobs to assemble build tools and all the packages needed to build Ruby anc creates archive files. These are installed by setup-ruby.
Regarding the transition to OpenSSL 3.0.x and the overlap with needing OpenSSL 1.1.1 for Rubies < 3.2, I think the best way to avoid issues is to create two sets of archive files in setup-msys2-gcc, one with 1.1.1, and one with 3.0.x.
The current archives are named
mingw64.7z
anducrt64.7z
. Maybe name the new archives (with OpenSSL 3.0.x)mingw64-3.0.7z
anducrt64-3.0.7z
?This will also require changes here in
windows.js
.The other option is to handle the OpenSSL change in setup-ruby-pkgs, but that would require people changing actions to use Ruby 3.2 on Windows. Not sure how many people would need it, but there also some people that may not know they need it. Right now, anyone using Windows Rubies with dependencies on Puma or EventMachine would need the OpenSSL files installed. There are probably more gems that require it.
Thoughts?
ping @eregon @larskanis @hsbt
Beta Was this translation helpful? Give feedback.
All reactions