Arch Linux

The reason for this change was to separate gem installed packages with pacman installed packages.

/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?

Since you pointed out that you are an admin, you should be aware that the --no-user-install option is available right?

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.

I wrote a message up to be displayed in post_install:

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.

I've seen post_install message. And I'm glad there are no such messages during Arch install. People don't read notices. Each notice is kind of excuse for bad job.

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.

"I've seen post_install message. And I'm glad there are no such messages during Arch install. People don't read notices. Each notice is kind of excuse for bad job."

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

I created a pkgrel 4 version of ruby with a post_install message.
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.