Skip to content

Conversation

hsbt
Copy link
Member

@hsbt hsbt commented Aug 22, 2022

No description provided.

deivid-rodriguez and others added 7 commits August 22, 2022 11:51
It's explicitly loaded when monkeypatching RubyGems, which we do very
early. So neither autoloading it, nor explicitly loading it anywhere
else is necessary.

rubygems/rubygems@fbc7a57161
The compact index should not request any marshaled gemspecs whatsoever.

rubygems/rubygems@6dbd44d0c0
When `--conservative` is passed, explicit unlocks are set for top level
gems via `@unlock[:gems]`, so that only those particular gems are
allowed to be updated.

When we compute the "base resolve" from the lockfile (the set of gems
whose versions should be kept pinned by the resolver), we always exclude
gems explicitly unlocked through `@unlock[:gems]` from it. This is done
by the `converge_specs` method.

However, the `converge_specs` method is also used for figuring out
additional lower bound requirements from the lockfile. But in this case,
even if gems are explicitly unlock in `@unlock[:gems]`, we still want to
add the additional requirement, so that gems are not downgraded by the
resolver.

So the solution is to move the line filtering out gems in
`@unlock[:gems]` from the `converged_specs` method out of that method,
so that it only applies for computing the "base resolve", but not the
addtional lower bound requirements.

rubygems/rubygems@405119bd7b
@hsbt hsbt merged commit c1ecc49 into ruby:master Aug 23, 2022
@hsbt hsbt deleted the merge-rubygems-head branch August 23, 2022 01:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants