Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
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 Andreas Radke (AndyRTR) - Tuesday, 28 February 2023, 17:34 GMT
Opened by Felipe Contreras (felipec) - Monday, 27 February 2023, 17:57 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 28 February 2023, 17:34 GMT
|
DetailsSince 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