Bug 1574594 - bundle install defaults to --system
Summary: bundle install defaults to --system
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: rubygem-bundler
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-03 15:36 UTC by Evgeni Golov
Modified: 2024-05-23 11:57 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-05-21 14:10:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1613864 0 unspecified CLOSED Pathing of SCLs built on top rh-ruby25 are wrong and lead to broken builds 2021-02-22 00:41:40 UTC
Ruby 14737 0 None None None 2018-05-04 10:39:52 UTC

Internal Links: 1613864

Description Evgeni Golov 2018-05-03 15:36:12 UTC
Description of problem:
Since the upgrade to F28, "bundle install" tries to install to /usr/share/gems even if the user did not pass --system.

Version-Release number of selected component (if applicable):
rubygem-bundler-1.16.1-3.fc28.noarch

How reproducible:
always

Steps to Reproduce:
1. run "bundle install" in any ruby project as a user

Actual results:
Your user account isn't allowed to install to the system RubyGems.
  You can cancel this installation and run:

      bundle install --path vendor/bundle

  to install the gems into ./vendor/bundle/, or you can enter your password
  and install the bundled gems to RubyGems using sudo.

  Password: 


Expected results:
Stuff is installed to ~/.gems

Additional info:
This worked fine in F27 and I tend to think this is a regression.

Comment 1 Evgeni Golov 2018-05-03 15:40:16 UTC
~/.gem, not ~/.gems, but that's not too relevant I guess :)

Comment 2 Vít Ondruch 2018-05-03 16:44:12 UTC
Oh my. Yes, there is was change in how RubyGems are installing the packages, which could be behind this. It seems Bundler guys are not going to respect that settings while they keeps breaking everything :( This will need some investigation ...

Comment 3 Vít Ondruch 2018-05-04 10:39:52 UTC
This is workaround:

https://wiki.archlinux.org/index.php/ruby#Bundler

Unfortunately, I really don't know if there is some proper fix. Therefore I filled upstream ticket.

Comment 4 Nat W. Garrison, Jr. 2018-06-16 22:07:33 UTC
I'm having the same problem with Fedora 28 Server, aarch64, loaded on a Raspberry Pi.  Besides the "bundle install" reporting the error, "rails new <project name>" reports the same error:

Your user account isn't allowed to install to the system RubyGems.
  You can cancel this installation and run:

      bundle install --path vendor/bundle

  to install the gems into ./vendor/bundle/, or you can enter your password
  and install the bundled gems to RubyGems using sudo.

  Password: 

I'm going to try the above fix that Vit Ondruch supplied.

Comment 5 Jun Aruga 2018-06-18 13:20:30 UTC
> Steps to Reproduce:
> 1. run "bundle install" in any ruby project as a user

About Evgeni Golov's case.
It means "run sudo bundle install" with sudo, right?

When I tried now, the outputted message was a little different.

Package versions

```
$ rpm -q ruby
ruby-2.5.1-93.fc28.x86_64

$ rpm -q rubygem-bundler
rubygem-bundler-1.16.1-3.fc28.noarch

$ cat Gemfile
source "https://rubygems.org"

gem 'minitest'
```

## "bundle install" by normal user without sudo => fails with an error.

```
[mockbuild@fc56022b8f0a483a90d046dc666d785e work]$ bundle install
Fetching gem metadata from https://rubygems.org/.............
Resolving dependencies...
Using bundler 1.16.1
Fetching minitest 5.11.3
Bundler::GemspecError: Could not read gem at /usr/share/gems/cache/minitest-5.11.3.gem. It may be
corrupted.
An error occurred while installing minitest (5.11.3), and Bundler cannot continue.
Make sure that `gem install minitest -v '5.11.3'` succeeds before bundling.

In Gemfile:
  minitest
```

## "sudo bundle install" by normal user => installed to /usr/share/gems/gems/

```
[mockbuild@fc56022b8f0a483a90d046dc666d785e work]$ sudo bundle install
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and installing your bundle as root
will break this application for all non-root users on this machine.
Fetching gem metadata from https://rubygems.org/.............
Resolving dependencies...
Using bundler 1.16.1
Using minitest 5.11.3
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

[mockbuild@fc56022b8f0a483a90d046dc666d785e work]$ bundle list
Gems included by the bundle:
  * bundler (1.16.1)
  * minitest (5.11.3)
```

## "bundle install" by root user => => installed to /usr/share/gems/gems/

```
<mock-chroot> sh-4.4# bundle install
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and installing your bundle as root
will break this application for all non-root users on this machine.
Fetching gem metadata from https://rubygems.org/.............
Resolving dependencies...
Using bundler 1.16.1
Fetching minitest 5.11.3
Installing minitest 5.11.3
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

<mock-chroot> sh-4.4# bundle list
Gems included by the bundle:
  * bundler (1.16.1)
  * minitest (5.11.3)
```

Comment 6 Jun Aruga 2018-06-18 14:04:39 UTC
About the case of Nat W. Garrison, Jr.,

My environment.

```
$ rpm -q ruby
ruby-2.5.1-93.fc28.x86_64

$ rpm -q rubygem-bundler
rubygem-bundler-1.16.1-3.fc28.noarch

$ rpm -q rubygem-rails
rubygem-rails-5.1.5-1.fc28.noarch
```

Then after installing ruby-devel, zlib-devel, rubygem-sqlite3 and sqlite-devel RPM packages.

I can recommend you to try below way. I could was success to install by normal user without error.

```
$ rails new foo --skip-bundle
$ cd foo
$ bundle install --path vendor/bundle
```

Comment 7 Nat W. Garrison, Jr. 2018-06-18 19:22:58 UTC
Adding "export GEM_HOME=$(ruby -e 'print Gem.user_dir')" to the end of my .bashrc file fixed my problem.  Now when I do a "bundle install" or a "rails new <project name>" I receive no errors and all of my gem files are in one location, /home/<user name>/.gem/ruby/gems. Also I don't have to include any command line options when I issue the above two commands.

Comment 8 Aleksandar Kostadinov 2018-07-17 08:24:11 UTC
Using GEM_HOME as far as I see makes ruby ignore the system wide /usr/share/gems.

What I did instead of setting GEM_HOME is to

> export BUNDLE_PATH=$(ls -t -U | ruby -e 'puts Gem.user_dir')

This makes bundle install to the user global dir but still read system wide dir.

The only issue is that `gem install` puts binaries in `~/bin` while `bundle install` puts them in `$BUNDLE_PATH/bin`. But it can be remedied by setting `PATH` or linking `~/bin` to `$BUNDLE_PATH/bin`.

Comment 9 Aleksandar Kostadinov 2018-07-17 08:38:36 UTC
pls ignore my last comment

Comment 10 Jun Aruga 2018-07-17 08:50:07 UTC
Aleksandar, about the "rails new <project>", you can refer our below testing note.
There are roughly 3 use cases to do it.

Testing Ruby on Rails 5.2.0 on Fedora rawhide
https://github.com/junaruga/fedora-blog/blob/master/2018-06-20-test-for-rails-5.2.md

Comment 11 "FeRD" (Frank Dana) 2018-11-09 18:36:57 UTC
I am really not even a little amused about bundler's flagrant misappropriation of the `sudo` command, especially when it's done by default and apparently without any option for disabling the misfeature. winetricks does the same thing, and I think they're just as wrong for all the same reasons.

I have my account configured for passwordless sudo. (I know, that makes this _technically_ my fault, but it was never a problem until software decided they could  just start running sudo commands without a by-your-leave, and relying on the assumption of password challenges by sudo to provide user notification/confirmation).

Despite the fact that this was supposedly fixed in bundler two years ago ( https://github.com/bundler/bundler/pull/4956 ), running bundler from rubygem-bundler-1.16.1-3.fc28.noarch on Fedora 28 most certainly did install a ton of gems into /usr/share/gems/, without any indication from me that it should be doing that. Worse, in the case of certain gems that have native code components, they didn't even install _correctly_, meaning I was being spammed with error messages every time I ran a gem/bundler command.

The `gem` command has `gem install --user-install` to place gems in ~/.gem/ruby/, but bundler explicitly doesn't support that ( https://github.com/bundler/bundler/issues/2565 ). They say ( https://github.com/bundler/bundler/issues/5113 ) that bundler 2.0 will default to a local install dir (./.bundle/) instead, but that was 2 years ago and there's still no bundler 2.0.

I'm going to open an issue (done: https://github.com/bundler/bundler/issues/6780) asking that they simply add, or accept patches to add, a configuration option that disables sudo abuse entirely. In bundler 1.16/1.17, which actually exist and are in use today, regardless what may or may not be the behavior of the vaporware bundler 2.0.

...Actually, at this point they're talking about bundler THREE-point-oh (https://github.com/bundler/bundler/issues/6779), which is hilarious because where even is 2.0?

Comment 12 Ben Cotton 2019-05-02 19:50:07 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 13 Evgeni Golov 2019-05-03 06:09:23 UTC
This still happens in F29, I didn't try F30 yet.

Comment 14 Ben Cotton 2019-10-31 19:25:26 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Vít Ondruch 2019-11-01 11:49:54 UTC
I don't think there was any change in this regard. Nevertheless, I am working upstream to resolve the issue (but I don't promise anything).

Comment 16 Ben Cotton 2020-02-11 15:45:32 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 17 Fedora Program Management 2021-04-29 16:50:12 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 Ben Cotton 2021-05-25 17:14:49 UTC
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 19 Evgeni Golov 2021-09-02 16:52:29 UTC
Still true in 34.

Comment 20 Ben Cotton 2022-05-12 16:41:05 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 21 Jun Aruga 2022-06-02 18:34:21 UTC
Still happens on Fedora 36.

```
$ which bundle
/bin/bundle

$ rpm -qf /bin/bundle
rubygem-bundler-2.3.7-164.fc36.noarch

$ bundle install
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Using bundler 2.3.7
Following files may not be writable, so sudo is needed:
  /usr/bin
  /usr/share/gems
  /usr/share/gems/build_info
  /usr/share/gems/cache
  /usr/share/gems/doc
  /usr/share/gems/extensions
  /usr/share/gems/gems
  /usr/share/gems/plugins
  /usr/share/gems/specifications
Fetching byebug 11.1.3
Installing byebug 11.1.3 with native extensions
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
```

Comment 22 Ben Cotton 2023-04-25 16:38:37 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 23 Ewoud Kohl van Wijngaarden 2023-05-23 08:29:29 UTC
Still affects Fedora 38

$ which bundle
/usr/bin/bundle

$ rpm -qf /usr/bin/bundle
rubygem-bundler-2.4.10-180.fc38.noarch

$ cat Gemfile
source 'https://rubygems.org'
gem 'byebug'

$ bundle install
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Using bundler 2.4.10
Fetching byebug 11.1.3

Retrying download gem from https://rubygems.org/ due to error (2/4): Bundler::PermissionError There was an error while trying to write to `/usr/share/gems/cache/byebug-11.1.3.gem`. It is likely that you need to grant write permissions for that path.

Retrying download gem from https://rubygems.org/ due to error (3/4): Bundler::PermissionError There was an error while trying to write to `/usr/share/gems/cache/byebug-11.1.3.gem`. It is likely that you need to grant write permissions for that path.

Retrying download gem from https://rubygems.org/ due to error (4/4): Bundler::PermissionError There was an error while trying to write to `/usr/share/gems/cache/byebug-11.1.3.gem`. It is likely that you need to grant write permissions for that path.

Bundler::PermissionError: There was an error while trying to write to `/usr/share/gems/cache/byebug-11.1.3.gem`. It is likely that you need to grant write permissions for that path.
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/shared_helpers.rb:105:in `rescue in filesystem_access'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/shared_helpers.rb:102:in `filesystem_access'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/rubygems_integration.rb:483:in `block in download_gem'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/retry.rb:40:in `run'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/retry.rb:30:in `attempt'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/rubygems_integration.rb:474:in `download_gem'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/source/rubygems.rb:484:in `download_gem'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/source/rubygems.rb:446:in `fetch_gem'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/source/rubygems.rb:430:in `fetch_gem_if_possible'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/source/rubygems.rb:158:in `install'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/installer/gem_installer.rb:54:in `install'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/installer/gem_installer.rb:16:in `install_from_spec'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/installer/parallel_installer.rb:156:in `do_install'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/installer/parallel_installer.rb:147:in `block in worker_pool'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/worker.rb:62:in `apply_func'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/worker.rb:57:in `block in process_queue'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/worker.rb:54:in `loop'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/worker.rb:54:in `process_queue'
  /usr/share/gems/gems/bundler-2.4.10/lib/bundler/worker.rb:90:in `block (2 levels) in create_threads'

An error occurred while installing byebug (11.1.3), and Bundler cannot continue.

In Gemfile:
  byebug

Comment 24 Aoife Moloney 2024-05-07 15:41:22 UTC
This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 25 Vít Ondruch 2024-05-10 10:52:17 UTC
Can somebody check with F40+? This change [1] might influence the behavior.



[1] https://src.fedoraproject.org/rpms/ruby/c/d3eaae9cc22d725b74dfdef3446b12d09fb1d9d1?branch=ruby-3.3

Comment 26 Aoife Moloney 2024-05-21 14:10:20 UTC
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 27 Evgeni Golov 2024-05-23 11:06:40 UTC
Vit, I can confirm that on F40 with
ruby-3.3.1-7.fc40.x86_64
rubygem-bundler-2.5.9-7.fc40.noarch

a "bundle install" as user drops things correctly in ~/.local/share/gem/ruby

Comment 28 Vít Ondruch 2024-05-23 11:57:55 UTC
(In reply to Evgeni Golov from comment #27)
> Vit, I can confirm that on F40 with
> ruby-3.3.1-7.fc40.x86_64
> rubygem-bundler-2.5.9-7.fc40.noarch
> 
> a "bundle install" as user drops things correctly in ~/.local/share/gem/ruby

Oh, nice. Super happy to hear that 😻


Note You need to log in before you can comment on or make changes to this bug.