fix(ruby): declare Apache Arrow repository in red-adbc.gemspec#4393
Merged
Conversation
red-adbc declared only its Debian/RHEL system package names (libadbc-glib-dev / adbc-glib-devel) without declaring the Apache Arrow repository those packages come from. It worked only because its dependency red-arrow registers the shared Apache Arrow APT/release repository first via its own gemspec. Bundler 4.0 (ruby/rubygems#9381) installs pure-ruby gems as soon as they are downloaded, without waiting for their native-extension dependencies. red-adbc is pure ruby and red-arrow is not, so red-adbc is installed first, its rubygems-requirements-system hook runs before the Arrow repository is registered, and libadbc-glib-dev cannot be found. Mirror red-arrow.gemspec's try -> add-repository -> retry for the debian and rhel platforms so red-adbc declares the repository for its own package and no longer depends on install order or on red-arrow.
otegami
added a commit
to otegami/activerecord-adbc-adapter
that referenced
this pull request
Jun 13, 2026
Ruby 4.0 ships Bundler 4.x, which installs pure-ruby gems before their native-extension dependencies finish building. red-adbc (pure-ruby) then runs rubygems-requirements-system's pre_install hook and requests libadbc-glib-dev before red-arrow has registered the Apache Arrow APT repository, so the parallel "bundle install" fails. Disable parallel install on 4.0 (--jobs=1) to restore dependency order, and drop the continue-on-error allow-failure so 4.0 is a real, blocking lane. Parallel native compile (MAKEFLAGS) is unaffected. Drop the workaround once the upstream fix ships: apache/arrow-adbc#4393
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
red-adbc.gemspec declares its Debian/RHEL package ( libadbc-glib-dev /
adbc-glib-devel) but not the Apache Arrow repository the package comes from, so
installing red-adbc relied on red-arrow registering that shared repository first.
Bundler 4.0's install-order change broke that assumption.
This mirrors what red-arrow.gemspec already does — try -> install
apache-arrow-apt-source -> retry for debian and rhel — so red-adbc declares the
repository for its own package and no longer depends on install order. Metadata
only; homebrew is unchanged.
Verifying the fix
Same setup as the reproduction in GH-4392, but with
red-adbc pointed at this branch instead of the released gem — bundle install
now succeeds. Only the red-adbc source line of the Gemfile changes:
Under Bundler 4.0 red-adbc still installs before red-arrow, but it now self-registers
the Apache Arrow repo and finds libadbc-glib-dev. repro-fix.sh builds red-adbc from the branch and pins the version to the published adbc-glib 1.11.0; amd64 required.
Closes #4392.