FS#77664 - [rubygems] Fix default install once and for all

Attached to Project: Community Packages
Opened by Felipe Contreras (felipec) - Monday, 27 February 2023, 17:57 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:05 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Anatol Pomozov (anatolik)
Andreas Schleifer (Segaja)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Since the beginning rubygems has installed gems in the wrong location: system directory (e.g. /usr/lib/ruby/gems/3.0.0). To fix this all Linux distributions have tried different approaches, but there isn't a single ideal solution.

Arch Linux opted for a configuration in /etc/gemrc, but that doesn't work for bundler. To workaround this problem the wiki suggests exporting GEM_HOME which works for both gem and bundler, but it's unreasonable to ask *all* users to do this.

In  FS#68757  it was suggested to always do this in /etc/profile.d/ruby.sh, but there are other solutions, like  FS#70961  which overrides Gem.default_dir with an operating_system.rb file (meant for distributions).

A much better solution is what the `rubygems-user` package in AUR does: add Gem.default_install with a patch, and then override it in operating_system.rb:

https://aur.archlinux.org/cgit/aur.git/plain/operating_system.rb?h=rubygems-user

Note that operating_system.rb is meant precisely for distributions to override the defaults, an many distributions provide such file, such as Feodra, Debian, and Gentoo.

Doing this closes many issues, such as  FS#68757 ,  FS#70959 ,  FS#70960 , and  FS#70961 , gets rid of the patch rubygems_stop_so_duplication.patch, and the custom /etc/gemrc. No need for all users to set GEM_HOME either.

Additionally, it gets rid of the RVM warning:

> * WARNING: Found --user-install in /etc/gemrc, please remove it, as it will break rubygems in RVM.
If it is intended or a mistake export rvm_ignore_gemrc_issues=1 to avoid this warning.

In  FS#68757  it was argued that upstream was going to fix the issue, but that was already more than 2 years ago, and the first reported issue was more than 12 years ago. I've counted at least 18 bug reports and they are all locked and/or closed only for a new one to be opened later.

That's why I created one in my personal repository to ensure it's not locked or closed until the issue is truly solved:

https://github.com/felipec/rubygems/issues/1

The general guideline to not patch upstream works fine on most projects where upstream is sensible, this is not the case here. The rubygems project is not being sensible and their stubbornness is causing problems for all Linux distributions, and all users. Moreover, a) we are already patching rubygems, and b) multiple solutions that do not require patching the code have been proposed, such as  FS#70961  and  FS#68757 .

There's no need to wait several years for something that is never going to come.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:05 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/rubygems/issues/1

Loading...