-
Notifications
You must be signed in to change notification settings - Fork 187
fix: ship an x86_64-linux-musl platform gem #194
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
Conversation
This was not strictly necessary before now because musl platforms have always used the generic platform gem, but recent changes in rubygems and bundler introduced new behaviors around libc flavors, and so we're going the extra mile here to be explicit. See #192 for context, also see rubygems/rubygems#5875
I'm going to wait a bit to hear back from rubygems/bundler maintainers that this is the appropriate thing to do here. Please don't merge yet. |
OK, seems like the bundler fix isn't going to ship for another week. I suspect this is low-priority for them because the majority of native platform gems can "fall back" safely to the vanilla platform (with a compilation penalty of some kind). This gem unfortunately cannot fall back, so ... I think we should merge this, and either
@dhh do you have a preference? I have a slight preference for 1 and will move forward with that plan later today unless you present objections. |
Hi! I'm sorry things broke. If I understand correctly, this only happens when using RubyGems 3.3.21 on Alpine, correct? Also note that if you release a |
Hey @deivid-rodriguez, that's correct, I can only reproduce the issue with rubygems 3.3.21 on musl (Alpine). I'm not confident this change actually makes things better for most people ... the issue I can most easily reproduce is the "looping" issue described at rubygems/rubygems#5871 Will this change fix that looping during bundler resolution? Can you suggest anything else we can do to work around this until an upstream fix is released? |
I think this PR should fix the looping, yes. But it may cause musl variants to get installed on glibc linux for users of old RubyGems. If the contents of the gems are exactly the same and you're just releasing them to workaround this issue, then I guess it doesn't matter although it's going to surprise people and feels wrong. I don't have a good suggestion for you as |
I tested this (installed the musl gem generated from this PR's branch on a glibc system) and it works OK. I don't feel strongly that we need to urgently address this -- we've only had one bug report, and there is a workaround ... though that may suddenly get more urgent if the default |
I think it's pretty much unreliable. Sometimes it will install the correct variant, sometimes it won't.
They don't do that anymore, actually. The alpine image comes with the default RubyGems version that comes with each Ruby. |
Sorry, I misunderstood this and my previous reply makes no sense. I see now, the gem would still work ok if the RubyGems bug was triggered and the musl variant got installed on non-musl platforms. Still feels wrong to me to publish separate variants if both work equally on both platforms. |
for what it's worth, I also experienced this. Installing the latest rubygems fixes another problem I had, but then it causes this defect. |
|
@raybradley the
Deivid's comment is saying "don't install the new version of rubygems or bundler if you're affected by this issue", not "roll back". Though, I do think he's saying that if your image installs rubygems 3.3.21 or bundler 2.3.21 and you are affected by this issue, you should update your image to not use those versions for now. |
Yes, sorry if I was not clear. What @flavorjones explained is exactly what I was saying. |
Ok think I got it...omitted |
OK, new version of rubygems and bundler dropped today but there's still problems on musl platforms, I've filed a bug upstream: rubygems/rubygems#5914 |
Clarifying my last comment: although there is still an issue with So I don't think we need this PR or a |
This was not strictly necessary before now because musl platforms have
always used the generic platform gem, but recent changes in rubygems
and bundler introduced new behaviors around libc flavors, and so we're
going the extra mile here to be explicit.
See #192 for context, also see
rubygems/rubygems#5875