Bundler tries to use wrong version of ruby

[LKirst]

Describe the problem as clearly as you can

I'm on openSUSE TW and so far I don't use a version manager for ruby. When I call bundle, I get an error that it cannot find ruby3.3:

$ bundle install
env: ‘ruby.ruby3.3’: No such file or directory

Did you try upgrading rubygems & bundler?

When I try to run gem update --system, I get a permission denied error, but if I'm not mistaken, I've updated gem with zypper as part of :

$ zypper if devel_ruby
Loading repository data...
Reading installed packages...


package 'devel_ruby' not found.

Information for pattern devel_ruby:
-----------------------------------
Repository      : Main Repository (OSS)
Name            : devel_ruby
Version         : 20170319-2.17
Arch            : x86_64
Vendor          : openSUSE
Installed       : Yes
Visible to User : Yes
Summary         : Ruby Development
Description     : 
    Tools and libraries for software development using the Ruby programming language.
Contents        : 
    S  | Name                           | Type    | Dependency
    ---+--------------------------------+---------+-----------
    i+ | patterns-devel-ruby-devel_ruby | package | Required
    i  | ruby                           | package | Required
    i  | ruby3.4-devel                  | package | Required

Here is my version of gem:

$ gem -v
3.6.2

Trying to update bundler results in the same error as bundle install

bundle update --bundler
env: ‘ruby.ruby3.3’: No such file or directory

Here is my RubyGems Environment:

gem env -v
RubyGems Environment:
  - RUBYGEMS VERSION: 3.6.2
  - RUBY VERSION: 3.4.1 (2024-12-25 patchlevel 0) [x86_64-linux-gnu]
  - INSTALLATION DIRECTORY: /home/myusername/gems
  - USER INSTALLATION DIRECTORY: /home/myusername/.local/share/gem/ruby/3.4.0
  - RUBY EXECUTABLE: /usr/bin/ruby.ruby3.4
  - GIT EXECUTABLE: /usr/bin/git
  - EXECUTABLE DIRECTORY: /home/myusername/gems/bin
  - SPEC CACHE DIRECTORY: /home/myusername/.cache/gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /etc
  - RUBYGEMS PLATFORMS:
     - ruby
     - x86_64-linux-gnu
  - GEM PATHS:
     - /home/myusername/gems
     - /home/myusername/.local/share/gem/ruby/3.4.0
     - /usr/lib64/ruby/gems/3.4.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => 1
     - :backtrace => true
     - :bulk_threshold => 1000
     - :benchmark => false
     - :install => "--format-executable --no-user-install"
     - "install" => "--format-executable --no-user-install"
     - :format_executable => true
     - :update => "--format-executable --no-user-install"
     - "update" => "--format-executable --no-user-install"
     - :sources => ["https://rubygems.org"]
  - REMOTE SOURCES:
     - https://rubygems.org
  - SHELL PATH:
     - /home/myusername/gems/bin
     - /home/myusername/gems/bin
     - /home/myusername/.local/bin
     - /home/myusername/bin
     - /usr/local/bin
     - /usr/bin
     - /bin

[deivid-rodriguez]

Can you look at the contents of the bundle script (which bundle should point you to it). I think it may have a wrong shebang.

[LKirst]

Thank you for your help! There is indeed an incorrect shebang at the beginning of the bundle script.

#!/usr/bin/env ruby.ruby3.3
#
# This file was generated by RubyGems.
#
# The application 'bundler' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'rubygems'

version = ">= 0.a"

str = ARGV.first
if str
  str = str.b[/\A_(.*)_\z/, 1]
  if str and Gem::Version.correct?(str)
    version = str
    ENV['BUNDLER_VERSION'] = str

    ARGV.shift
  end
end

if Gem.respond_to?(:activate_bin_path)
load Gem.activate_bin_path('bundler', 'bundle', version)
else
gem "bundler", version
load Gem.bin_path("bundler", "bundle", version)
end

I edited the file and corrected the shebang.

How could I have avoided this? Is it a bug or did I do something wrong during the update?

[deivid-rodriguez]

Normally, when RubyGems is upgraded, all binstubs are rewritten to have their shebangs point to the running version of Ruby (there's a --regenerate-binstubs option to gem update --system that's enabled by default). However, I'm not sure how OpenSuse packages and upgrades RubyGems. It could be an issue in how the package/upgrade RubyGems. And there could also be some room for improvement on our side to make this kind of issue harder to happen.

If you can point me to the sources of the openSUSE package for RubyGems, that'd be a start to dig in more!

[LKirst]

Thank you for your answer. I think the source for the openSUSE package for RubyGems can be found here: https://build.opensuse.org/project/show/devel:languages:ruby

[deivid-rodriguez]

Cool, thank you!

I see @darix, who has reported several issues to us in the past (usually because I broke stuff 😅), is a maintainer there. So polite ping in case they have insights about what could be wrong here and how we can prevent this kind of issue.

[darix]

something in your environment probably remembered that openSUSE Tumbleweed used to be on ruby 3.3. but our default ruby in the mean time switched to ruby3.4. if possible switch your app to use ruby 3.4. or if you really want 3.3 back you can do

zypper ar obs://devel:languages:ruby obs-devel:languages:ruby
zypper ref
zypper in ruby3.3

hth

p.s.: I would recommend finding where your app remembered the ruby 3.3 thing and switch it to 3.4 :)
if you are lucky all you need is perl -p -i -e 's|ruby.ruby3.3|ruby.ruby3.4|g' bin/* in your rails app.

as a small explanation for the background:

we structured all our ruby packages so that you can install them in parallel, so the ruby binaries have ruby.rubyX.Y as name. there is a /usr/bin/ruby which is currently a hardlink to what we consider the default ruby. our gemrc also has the flag set to suffix the stub files. and the unversioned file name is then handled by update-alternatives.

but the nice thing of this is:

1. we can install many ruby versions in parallel
2. we can build rubygems based packages for many ruby versions in parallel from a single spec file.

if any of you got more questions about our packaging feel free to ask.

oh btw we can even package rails apps nicely - even monsters like gitlab or discourse :D