FS#29292 - Recent ruby package change breaks use cases
Attached to Project:
Arch Linux
Opened by Sergey Kish (sergeykish) - Thursday, 05 April 2012, 14:27 GMT
Last edited by Thomas Dziedzic (tomd123) - Sunday, 08 April 2012, 22:30 GMT
Opened by Sergey Kish (sergeykish) - Thursday, 05 April 2012, 14:27 GMT
Last edited by Thomas Dziedzic (tomd123) - Sunday, 08 April 2012, 22:30 GMT
|
Details
Description:
New ruby PKGBUILD changes default gem install path to $HOME/.gem Lets check use cases As a user I want markdown interpreter $ gem install bluecloth Fetching: bluecloth-2.2.0.gem (100%) WARNING: You don't have /home/sergeykish/.gem/ruby/1.9.1/bin in your PATH, gem executables will not run. Building native extensions. This could take a while... Successfully installed bluecloth-2.2.0 1 gem installed Installing ri documentation for bluecloth-2.2.0... Installing RDoc documentation for bluecloth-2.2.0... $ bluecloth bluecloth: No such file or directory As smart, experienced user I could read WARNING and change $PATH But if I'm smart enough wouldn't I put that option in ~/.gemrc myself? $ PATH=$PATH:/home/sergeykish/.gem/ruby/1.9.1/bin $ bluecloth -f # how many experienced users are there? <h1>how many experienced users are there?</h1> As admin I want to update gems # gem update --system Updating rubygems-update Fetching: rubygems-update-1.8.17.gem (100%) WARNING: You don't have /root/.gem/ruby/1.9.1/bin in your PATH, gem executables will not run. Successfully installed rubygems-update-1.8.17 ERROR: While executing gem ... (Errno::ENOENT) No such file or directory - /usr/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.17 I'm updating system gems. That shouldn't be done in /root/.gems Given passenger gem there should it be installed? Root installs systemwide, think of `gem install` as `make && make install` Explicit configuration required to change install path. With `./configure --prefix=$HOME/foo && make && make install` or `gem install --user-install` whatever For several years of active development there were no issues with ruby on Arch. Several users already faced that problem. Core should be simple, predicteble. One wishing flexibility could use RVM, RbEnv, Bundler - there are many ways to handle different ruby and gem versions on development computer. I couldn't belive introducing such magic is Arch way. Additional info: * ruby-1.9.3_p125-3 Steps to reproduce: * Install latest ruby `pacman -S ruby` * Follow description |
This task depends upon
Closed by Thomas Dziedzic (tomd123)
Sunday, 08 April 2012, 22:30 GMT
Reason for closing: Fixed
Additional comments about closing: added a post_install to help people realize where the default gem install location is in pkgrel 4
Sunday, 08 April 2012, 22:30 GMT
Reason for closing: Fixed
Additional comments about closing: added a post_install to help people realize where the default gem install location is in pkgrel 4
/usr/lib should stay off limits for programs that are not the package manager afaik.
Since you pointed out there is some confusion, do you think a post_install message would suffice?
http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February/022609.html
I might just close this bug and add a post_install message mentioning the defaults in the post I just linked.
Awaiting for feedback.
The default location of gem installs is $HOME/.gem/ruby
Add the following line to your PATH if you plan to install using gem
$(ruby -rubygems -e "puts Gem.user_dir")/bin
If you want to install to the system wide location, you must either:
edit /etc/gemrc or run gem with the --no-user-install flag.
Things should work by default. Given new user with clean install. He wants to update gems as described the web.
$ sudo gem update --system
Updating rubygems-update
Fetching: rubygems-update-1.8.17.gem (100%)
WARNING: You don't have /root/.gem/ruby/1.9.1/bin in your PATH,
gem executables will not run.
Successfully installed rubygems-update-1.8.17
ERROR: While executing gem ... (Errno::ENOENT)
No such file or directory - /usr/lib/ruby/gems/1.9.1/gems/rubygems-update-1.8.17
Now he is in the trouble. For some reason gem installed in /root/.gems. And `gem update --system` don't expect such behaviour. Looks like he have to add /root/.gems/bin/ in his $PATH. My /root/ is empty. So it's wrong way.
User could also search web what's wrong with his gems. But nobody else, noone distro made such thing. Even Ubuntu.
Things should work by default. Flags that makes things work aren't acceptable. `pacman --dont-install-broken-packages`, `cat --i-dont-want-version-info-in-stdou` are examples of bad design. That's why they imagined.
> /usr/lib should stay off limits for programs that are not the package manager afaik.
It's my computer afaik. Separating install places reminds me sad story of
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
/opt
If it's pacmans than it should lay in /pacman. Only in this case it would not be polluted by gem, pip, cpan to name a few. Pacman adds value to make system, not replaces it. Everything could be installed with `make && make install`. Including /usr/lib content.
What's the point of separation? If it's resolving conflicts, user better knows his conflicts. He can use install path with ~/.gemrc, use RVM, Bundler. All these tools affect current user, not system settings. And you know about rip? Another gems manager. How do you think is it affected by /etc/gemrc? Hardly believe.
If people choose to ignore important messages, then they are also choosing to have potential problems.
"Things should work by default. Given new user with clean install. He wants to update gems as described the web."
Things do work by default. You are just assuming old default behavior. "He" should also be aware of how his system behaves and include that into his decision making.
"Now he is in the trouble. For some reason gem installed in /root/.gems. And `gem update --system` don't expect such behaviour. Looks like he have to add /root/.gems/bin/ in his $PATH. My /root/ is empty. So it's wrong way."
I will add a post_install message to make sure users are aware of the change, after that, there should be little confusion. Adding /root/.gems/bin to your PATH is completely incorrect. Gem is meant to be used as a user now, not with sudo!
"User could also search web what's wrong with his gems. But nobody else, noone distro made such thing. Even Ubuntu."
It's too bad, but there are always going to be incompatibilities with other distros, this is one of them.
"Things should work by default. Flags that makes things work aren't acceptable. `pacman --dont-install-broken-packages`, `cat --i-dont-want-version-info-in-stdou` are examples of bad design. That's why they imagined."
They do work by default, you need to adjust to the default behavior. Flags that change default behavior are acceptable, that's why they exist. I can't make everyone happy, but I believe per user gem installs is going to be nicer and cleaner in the long run.
"It's my computer afaik. Separating install places reminds me sad story of"
Those locations should all be managed by pacman. I have to worry about providing a nice default for everyone's computer, not just what suits me best.
"If it's pacmans than it should lay in /pacman. Only in this case it would not be polluted by gem, pip, cpan to name a few. Pacman adds value to make system, not replaces it. Everything could be installed with `make && make install`. Including /usr/lib content."
I'm not sure if I fully understand you.
If you want to mess up your clean system with programs outside of pacman, you can, but I would prefer it if the default behavior didn't do this.
"What's the point of separation? If it's resolving conflicts, user better knows his conflicts. He can use install path with ~/.gemrc, use RVM, Bundler. All these tools affect current user, not system settings. And you know about rip? Another gems manager. How do you think is it affected by /etc/gemrc? Hardly believe."
The point of separation is to separate gems managed by pacman with gems managed with gem. You have used ignorance as an excuse for the user to make a case against changing default behavior so far, yet now you point out that the user should know his system. I use both rvm and bundler, both work fine with this current default setting. If these programs are affected by the gemrc, then they should be changed to ignore the system gemrc. I've never used rip, nor do I know how it works, but I don't maintain it either. I can't possibly account for all programs in existence. I can only account for the gem command's behavior.
As far as I see, this has been nothing more than a rant.
You have failed to address the issue which is, how would you suggest gem behave so that it doesn't touch directories that should be managed solely by pacman.
Here is the full discussion of the proposal..
http://mailman.archlinux.org/pipermail/arch-general/2012-February/025012.html
Hopefully this will help people figure out the new default behavior.
I will keep this br open for another day if you want to bring up anything else.