If both a native and a generic version are locked, but the native
version is incompatible with the running Ruby, Bundler will still keep
the native version in the lockfile, since it could be potentially useful
when using other rubies.
However, when `bundle update` is run, this was not the case because the
locked native gems were not using the right source when materializing.
They were using the lockfile source instead of the Gemfile source, and
that meant they could not be found when materializing, because the
lockfile source always uses local mode so does not see them.
The effect of this was normally that they were incorrectly removed from
the lockfile and a strange "this spec has been possibly yanked" was
printed in verbose mode. However, in certain situations (i.e., when the
generic gem would bring extra dependencies), it could also make `bundle
update` crash.
The solution is, when adding this extra locked specs to the result after
resolving, maybe sure they inherit the source from the resolved specs,
so they can be found when materializing.
`bundle install` did not have the issue because it passes locked specs
to the resolver, and assigns the right source to them in
`Definition#converge_locked_specs`.
https://github.com/rubygems/rubygems/commit/91ce881fda