Support non-gnu libc linux platforms

[lloeki]

I will abide by the code of conduct.

What was the end-user or developer problem that led to this PR?

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.

Followup to #2922
Closes #3174

What is your fix for the problem, implemented in this PR?

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.

Impact of this change is expected to be limited to none, as *-linux gems working on non-*-linux platforms such as *-linux-musl are vanishingly rare due to the stringent requirements and moves required to produce them. Therefore, as codified in the codebase preceding this pull request, it can be assumed that the set of gems published as *-linux is strictly equal to the set of gems that would be marked -linux-gnu only (if that were a thing).

Alternative considered: implement an additional, optional @libc attribute, thus setting the @version one to be always nil for an @os being 'linux'. This would do away with some of the hacks in there, but would significantly alter the existing code for very little immediate value, and would break code currently depending on checking for @version being musl on recent rubygems.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[welcome]

Thanks for opening a pull request and helping make RubyGems and Bundler better! Someone from the RubyGems team will take a look at your pull request shortly and leave any feedback. Please make sure that your pull request has tests for any changes or added functionality.

We use GitHub Actions to test and make sure your change works functionally and uses acceptable conventions, you can review the current progress of GitHub Actions in the PR status window below.

If you have any questions or concerns that you wish to ask, feel free to leave a comment in this PR or join our #rubygems or #bundler channel on Slack.

For more information about contributing to the RubyGems project feel free to review our CONTRIBUTING guide

[deivid-rodriguez]

Hi @lloeki, thanks so much for this!

I'm sorry it took me so long to look at it since it seems like a very interesting PR. As far as I understand, it unblocks sassc-ruby from providing a precompiled version. And sassc-ruby is the gem I'm aware of with the extension that takes the most to compile.

[lloeki]

I'm sorry it took me so long to look at it since it seems like a very interesting PR

No worries :) I'm glad it's being considered!

This is a big conundrum, and the patch here presents an "ideal" version of a fix: I feel compelled to tell you that I am wondering how to handle the merge of this patch once merged.

Indeed people will eventually start pushing linux-musl gems (they don't currently because it's not working on musl, but once it does...), and non-up-to-date rubygems running on glibc (hence linux) may try to fetch linux-musl binaries, possibly wreaking havoc in currently working setups.

It all depends on what the gem server returns as a resultset and the order in which gem matches and dependencies are processed, but it does happen. You can try it with either gem or bundle against the libv8-node gem (which has linux and linux-musl versions published) to wrap your head around it.

As far as I understand, it unblocks sassc-ruby from providing a precompiled version

That's one of the blockers, yes.

And sassc-ruby is the gem I'm aware of with the extension that takes the most to compile.

I assume you have never tried to build libv8 from source do you? ;) j/k, sassc is indeed a painful one. Nokogiri is a nice one too. In fact, anything involving C++ is generally a pain.

[lloeki]

Indeed people will eventually start pushing linux-musl gems (they don't currently because it's not working on musl, but once it does...), and non-up-to-date rubygems running on glibc (hence linux) may try to fetch linux-musl binaries, possibly wreaking havoc in currently working setups.

@deivid-rodriguez seems like my concerns are unwarranted, libv8-node has both linux and linux-musl gems published and everything works as expected:

# recent ruby
docker run --rm -it ruby:2.7 /bin/sh -c 'gem install libv8-node -v 15.5.1.0.beta1'
docker run --rm -it ruby:2.7 /bin/sh -c 'git clone https://github.com/lloeki/rubygems.git --branch support-non-gnu-libc-linux && cd rubygems && rake setup && ruby -Ilib bin/gem install libv8-node -v 15.5.1.0.beta1'
# old ruby (oldest supported by current rubygems)
docker run --rm -it ruby:2.3 /bin/sh -c 'gem install libv8-node -v 15.5.1.0.beta1'
docker run --rm -it ruby:2.3 /bin/sh -c 'git clone https://github.com/lloeki/rubygems.git --branch support-non-gnu-libc-linux && cd rubygems && rake setup && ruby -Ilib bin/gem install libv8-node -v 15.5.1.0.beta1'
# older ruby (no clone of branch because no support from current rubygems)
docker run --rm -it ruby:2.0 /bin/sh -c 'gem install libv8-node -v 15.5.1.0.beta1'
# on musl, without fix, picks the wrong one (expected)
docker run --rm -it ruby:2.3-alpine /bin/sh -c 'gem install libv8-node -v 15.5.1.0.beta1'
docker run --rm -it ruby:2.7-alpine /bin/sh -c 'gem install libv8-node -v 15.5.1.0.beta1'
# on musl, with fix, picks the correct one
docker run --rm -it ruby:2.3-alpine /bin/sh -c 'apk add build-base git && git clone https://github.com/lloeki/rubygems.git --branch support-non-gnu-libc-linux && cd rubygems && rake setup && ruby -Ilib bin/gem install libv8-node -v 15.5.1.0.beta1'
docker run --rm -it ruby:2.7-alpine /bin/sh -c 'apk add build-base git && git clone https://github.com/lloeki/rubygems.git --branch support-non-gnu-libc-linux && cd rubygems && rake setup && ruby -Ilib bin/gem install libv8-node -v 15.5.1.0.beta1'

So the fix and its ultimate impact presented here appears to work in all cases.

[lloeki]

@deivid-rodriguez resolved review and rebased onto master.

[deivid-rodriguez]

@lloeki This is awesome, thanks for your work. I reviewed it and it looks just fine to me! 🎉.

Only thing I noticed is that it doesn't seem actually rebased? First commit before your changes is from last November, it seems? https://github.com/rubygems/rubygems/commits/26f3bd99973d97ecadf247f61a2cf0973dbb58dd.

Can you rebase it just to make sure it's all still ✔️? And while at it, I'd squash the last commit into the first one.

[lloeki]

Huh. Not sure what I did there, maybe I forgot to rebase on the correct remote. Go figure, it should be correctly rebased now.

[deivid-rodriguez]

The squashing I suggested was not a big deal, so I'm merging this. Thanks so much for this fix @lloeki, I expected to release it very soon.

[lloeki]

Ah sorry about the squash, I was scratching my head a bit to much about why I messed up the rebase and forgot about it ^^’. Thanks!

[deivid-rodriguez]

No worries!