Skip to content
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

Fallback to selecting installable candidates if possible when materializing specs #6225

Merged
merged 4 commits into from
Jan 4, 2023

Conversation

deivid-rodriguez
Copy link
Member

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

When running in legacy lockfile mode (only RUBY platform locked in Gemfile.lock), it may happen that we select a platform specific version, only to later find that it's not installable because of not matching ruby version requirements.

This is the case when having nokogiri-1.3.10 in this kind of lockfile. This version of nokogiri only supports Ruby 3.2 in its generic version (though a "Ruby >= 2.6" requirement), but there are no yet precompiled versions for Ruby 3.2, so those don't support Ruby 3.2 (they use a ">= 2.6, < 3.2.DEV" requirement).

So when upgrading such a lockfile to Ruby 3.2, we would incorrectly select a precompiled version, and fail to materialize it.

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

Check the above situation before-hand so that we can fallback to the generic version.

Closes #6221.

Make sure the following tasks are checked

@deivid-rodriguez deivid-rodriguez changed the title Fallback to selecting installable candidates when materializing specs Fallback to selecting installable candidates if possible when materializing specs Jan 2, 2023
@deivid-rodriguez deivid-rodriguez marked this pull request as ready for review January 2, 2023 15:01
When running in legacy lockfile mode (only RUBY platform in lockfile),
it could happen that a specific candidate for the current platform is
selected that's not actually installable for the current Ruby due to not
matching Ruby version requirements. Check this case before hand so that
we can use the generic version instead.
@deivid-rodriguez deivid-rodriguez merged commit 6c979fa into master Jan 4, 2023
@deivid-rodriguez deivid-rodriguez deleted the fix-upgrading-ruby-issue branch January 4, 2023 20:49
deivid-rodriguez added a commit that referenced this pull request Jan 6, 2023
Fallback to selecting installable candidates if possible when materializing specs

(cherry picked from commit 6c979fa)
hsbt pushed a commit that referenced this pull request Jun 1, 2023
Instead of resolving to correct Ruby platform, it preferred the
archful package, that is actually incompatible.

See sclorg/s2i-ruby-container#469
for an example of the bug.

Commit taken from:
<#6225>
and adapted:
<7b64c64>
for the PR#6225.
hsbt pushed a commit that referenced this pull request Jun 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrading to Ruby 3.2 and Bundler 2.4.1 hangs on "Resolving dependencies..."
1 participant