-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support non gnu libc linux platforms #5852
Conversation
The symmetry with the "for command line" case is made more apparent.
On past versions there were observed cases of inconsistencies when some platforms were re-parsed. Ensure that a platform's string representation parses again in a platform object equal to the original.
Attempting to install a gem published as both *-linux and *-linux-musl results in the incorrect gem being picked up, causing build failures due to binary incompatibility. This is caused by the `nil` wildcard swallowing the libc information upon version comparison. Handle the linux case by performing only non-wildcard equality on the version and asserting 'gnu' and nil equivalence, while preserving the current behaviour for other OSes. Co-authored-by: Loic Nageleisen <loic.nageleisen@gmail.com>
Let's do this! |
gem install
support non gnu libc linux
Thank you David! |
Make `gem install` support non gnu libc linux (cherry picked from commit 9dc737d)
A tip for those who are publishing linux-gnu or linux-musl specific gems: make sure you add rubygems < 3.3.22 have the following problems:
Update: debian unstable's ruby 3.1 has rubygems 3.4.20, but is patched to effectively reverted this change all together and is basically broken: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069089 If you want to avoid debian unstable users spamming weird bug reports, you may need to |
In https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6242, we dropped support for updating RubyGems in favor of using the version shipped by Ruby. However, that version may be outdated. For example, Ruby 3.0.5 ships with RubyGems v3.2.33, but for native gems that ship with precompiled musl extensions, we need to make sure we use RubyGems >= 3.3.22 (rubygems/rubygems#5852). This is to ensure Omnibus GitLab does not install the wrong native extension. Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/408338 Changelog: changed
…ch64-linux-gnu **What does this PR do?** This PR fixes platform detection not working correctly when the user's platform is `x86_64-linux-gnu`/`aarch64-linux-gnu`. This manifested to a user as the following error: > Profiling was requested but is not supported, profiling disabled: Your > ddtrace installation is missing support for the Continuous Profiler > because the `libdatadog` gem installed on your system is missing > binaries for your platform variant. > (Your platform: `x86_64-linux-gnu`) > (Available binaries: `x86_64-linux`, `x86_64-linux-musl`) In the past, rubygems did this normalization for us (we even had a comment mentioning it in the code!) but this was removed in rubygems/rubygems#5852 for Rubygems 3.4+ I'm also bumping the `GEM_MAJOR_VERSION` in the `version.rb` file so I can release this fix as libdatadog 6.0.0.2.0 for Ruby as soon as this PR is merged. **Motivation:** Make sure our platform detection code is correct. **Additional Notes:** N/A **How to test the change?** This change includes test coverage.
What was the end-user or developer problem that led to this PR?
gem install
may end up installing musl-specific variants on non musl platforms.What is your fix for the problem, implemented in this PR?
Make platform comparison and initialization support must and other non gnu lib linux.
NOTE: This is extracted from #4488, but focusing on the RubyGems side. #4488 will deal with adapting the Bundler side to cherry-pick the proper changes, so that
bundle install
works consistently across the different RubyGems versions.Fixes #3174.
Make sure the following tasks are checked