ruby 1.9 vs. rubygems

FreakGuard · 2009-10-26 10:24:17

Name           : ruby
Version        : 1.9.1_p243-2
Conflicts With : rubygems  rake

I suppose that implies rubygems is now packed with ruby. But there's a problem:

$ gem --version
1.3.1
$ pacman -Si rubygems
Version        : 1.3.3-1

I need the newer version due to datamapper Rakefiles

dannytatom · 2009-10-26 10:32:56

~/ ruby -v
ruby 1.9.1p243 (2009-07-16 revision 24175) [i686-linux]
~/ gem -v
1.3.5

Try running `sudo gem update --system`?

FreakGuard · 2009-10-26 15:17:49

Not the way I like it, but it works. :-)

dannytatom · 2009-10-26 20:21:35

Well now that rubygems is built in, you can't really depend on the package manager to keep it up to date. Having it built in definitely makes distribution easier as anyone who has ruby installed has rubygems.

cro · 2009-11-16 19:24:30

dannytatom wrote:

Well now that rubygems is built in, you can't really depend on the package manager to keep it up to date. Having it built in definitely makes distribution easier as anyone who has ruby installed has rubygems.

1. Why can't I depend on the package manager to keep it up to date? Isn't that what a package manager is there for, keeping packages up to date?
2. Why does it make distribution easier? Pacman has mechanisms for that, e.g. to simply define ruby and the rubygems package as dependencies of packages that need ruby and rubygems installed. Doesn't it make it harder, because you now should update the ruby package also every time rubygems becomes outdated?
3. Doesn't "gem update --system" conflict with pacman's package management because pacman does not know what files are added or removed by the internal rubygem update.
4. Sorry to say this, but stuff like this reminds me of Windows drawbacks, where every application might have its own update functionality. Very ugly.

Allan · 2009-11-16 23:09:51

Or instead of ranting you could do something productive and file a feature request asking for ruby-gems to be split out of ruby...

cro · 2009-11-17 02:46:26

Allan wrote:

Or instead of ranting you could do something productive and file a feature request asking for ruby-gems to be split out of ruby...

I think the principles are important.
Sorry, if my English sounds like ranting.

EDIT: I don't have a problem with rubygems being part of the ruby package, but while it is, the package should be updated when its contents becomes outdated.

Last edited by cro (2009-11-17 03:01:48)

cro · 2009-12-03 01:13:00

Please update the ruby package (with the up-to-date version of rubygems) or tell me how to file a "feature request asking for ruby-gems to be split out of ruby". Btw. is there a documentation on how formalities like filing a feature request and stuff are done in the archlinux community?

Last edited by cro (2009-12-03 01:14:40)

lucke · 2009-12-03 01:23:53

You can file a feature request at bugs.archlinux.org.

http://wiki.archlinux.org/index.php/Rep … Guidelines

dannytatom · 2009-12-03 01:33:21

cro wrote:

1. Why can't I depend on the package manager to keep it up to date? Isn't that what a package manager is there for, keeping packages up to date?

That is indeed what package managers are for, and rubygems is a package manager. I guess I should've clarified my original statement.

cro wrote:

2. Why does it make distribution easier? Pacman has mechanisms for that, e.g. to simply define ruby and the rubygems package as dependencies of packages that need ruby and rubygems installed. Doesn't it make it harder, because you now should update the ruby package also every time rubygems becomes outdated?

No, you don't. You update rubygems via 'sudo gem update --system'. Same way you update your gems, but with the --system option so that it updates rubygems itself as well.

cro wrote:

3. Doesn't "gem update --system" conflict with pacman's package management because pacman does not know what files are added or removed by the internal rubygem update.

As far as I know, pacman could care less, as it's not handeling the files, rubygems is.

Edit: cro clarified in his edit, making part of my response irrelevant.

Anywho, if you've got a problem with it, my suggestion is posting it to the ruby mailing list. http://www.ruby-forum.com/

Last edited by dannytatom (2009-12-03 01:34:45)

archlinuxsagi · 2009-12-03 04:31:32

dannytatom wrote:

As far as I know, pacman could care less, as it's not handeling the files, rubygems is.

So what will happen if ruby is upgraded through pacman? what will be the rubygem version be? Will it be "downgraded"?
User still need to perform "gem update --system?

I currently having issues with gemcutter and I am running it on my test system. I am just concern if "gem update --system" will conflict with update of ruby through pacman.

cro · 2009-12-03 15:12:32

lucke wrote:

You can file a feature request at bugs.archlinux.org.
http://wiki.archlinux.org/index.php/Rep … Guidelines

Thanks.

dannytatom wrote:

cro wrote:
1. Why can't I depend on the package manager to keep it up to date? Isn't that what a package manager is there for, keeping packages up to date?
That is indeed what package managers are for, and rubygems is a package manager. I guess I should've clarified my original statement.

lol, rubygems is the package manager for the gems but NOT for itself! Pacman is responsible for the software called 'rubygems'.

dannytatom wrote:

cro wrote:
2. Why does it make distribution easier? Pacman has mechanisms for that, e.g. to simply define ruby and the rubygems package as dependencies of packages that need ruby and rubygems installed. Doesn't it make it harder, because you now should update the ruby package also every time rubygems becomes outdated?
No, you don't. You update rubygems via 'sudo gem update --system'. Same way you update your gems, but with the --system option so that it updates rubygems itself as well.

This is bad. The gems are updated by rubygems, ok, this is cumbersome, but ok, works fine with pacman since the directory where the gems are placed is therefore managed by rubygems. But rubygems (the gems manager) is content of a package managed by pacman, be it 'ruby' or 'rubygems' that doesn't matter. So changes by updating rubgems (the gems manager) by itself will conflict with pacman.

dannytatom wrote:

cro wrote:
3. Doesn't "gem update --system" conflict with pacman's package management because pacman does not know what files are added or removed by the internal rubygem update.
As far as I know, pacman could care less, as it's not handeling the files, rubygems is.

Just for the gems. pacman is definitely handling the files of rubygems (the gems manager).

dannytatom · 2009-12-04 02:02:51

archlinuxsagi wrote:

I currently having issues with gemcutter and I am running it on my test system. I am just concern if "gem update --system" will conflict with update of ruby through pacman.

I assume the rubygems version will stay the same when you update ruby. I honestly have no clue, have yet to get an update. What gemcutter problems are you having?

cro wrote:

lol, rubygems is the package manager for the gems but NOT for itself! Pacman is responsible for the software called 'rubygems'.

But there isn't a 'rubygems' package anymore, it's now part of ruby itself.

cro wrote:

This is bad. The gems are updated by rubygems, ok, this is cumbersome, but ok, works fine with pacman since the directory where the gems are placed is therefore managed by rubygems. But rubygems (the gems manager) is content of a package managed by pacman, be it 'ruby' or 'rubygems' that doesn't matter. So changes by updating rubgems (the gems manager) by itself will conflict with pacman.

I'm assumin' the ruby-core team has thought through enough so that nothing will break between updates.

cro wrote:

Just for the gems. pacman is definitely handling the files of rubygems (the gems manager).

Honestly have no clue about this.

cro · 2009-12-11 00:03:53

dannytatom wrote:

cro wrote:
lol, rubygems is the package manager for the gems but NOT for itself! Pacman is responsible for the software called 'rubygems'.
But there isn't a 'rubygems' package anymore, it's now part of ruby itself.

That is exactly what I am saying. But it doesn't matter if the files of rubygems are in 'rubygems' or in 'ruby', they are handled by pacman and the package they are in should be updated when they become outdated.

dannytatom wrote:

cro wrote:
This is bad. The gems are updated by rubygems, ok, this is cumbersome, but ok, works fine with pacman since the directory where the gems are placed is therefore managed by rubygems. But rubygems (the gems manager) is content of a package managed by pacman, be it 'ruby' or 'rubygems' that doesn't matter. So changes by updating rubgems (the gems manager) by itself will conflict with pacman.
I'm assumin' the ruby-core team has thought through enough so that nothing will break between updates.

Well, the ruby-core team as well as the rubygems developers do know nothing about pacman and Arch Linux packaging policies. Why should they? That is one of many reasons why updating rubygems by itself on Arch Linux is a bad idea.

lolilolicon · 2009-12-19 11:31:48

So the relevant part is rubygems related files.
What pacman will manage are those files listed by:

pacman -Ql ruby | grep gems

They are the rubygems manager itself.
And what rubygems manager will manage are the "gems" _plus_ itself.

So I'm guessing pacman will always replace the files listed by the above command.
Assuming we're very bleeding edge and don't want pacman to downgrade our newest rubygems manager, I'm thinking of using the NoUpgrade flag in pacman.conf(QQ: does it support regex?), but I don't know a way to prevent pacman from writing the .pacnew files there.
Or maybe we are not that bleeding edge? Then we will rely on pacman to upgrade the rubygems manager for us, assuming the ruby package will be upgraded often enough by the maintainer so the rubygems manager will always function properly.

I'm very new to ruby and have not yet used gems for the very first time, so I may be missing some point regarding how the gems manager works.(I hope it's smart enough.)

If you ask me, I'd prefer the rubygems package being split from the ruby package, so:
For the very bleeding-edge type of rubyists, they do once `pacman -S rubygems' and then put rubygems in IgnorePkg, letting the gems manager manage itself.
For the not-so-bleeding-edge type, they can still rely on pacman like they always did.

cro, did you file a request/bug report to the bugtracker?

Teoulas · 2009-12-19 12:09:32

lolilolicon wrote:

I'm very new to ruby and have not yet used gems for the very first time, so I may be missing some point regarding how the gems manager works.(I hope it's smart enough.)

Gems are installed in /usr/lib/ruby/gems, if you run the gem command as root and in your home directory (under .gem), if you run it as a normal user. Rubygems is not updated, if you just run 'gem update', it only updates installed gems. If you want rubygems to update itself you can run 'gem update --system'.

cro · 2009-12-23 20:36:44

lolilolicon wrote:

[...] Then we will rely on pacman to upgrade the rubygems manager for us, assuming the ruby package will be upgraded often enough by the maintainer so the rubygems manager will always function properly. [...]

That is the part where it is going wrong at the moment.
A package split might help. And it might make the things possible you said about bleeding edge with ruby.

lolilolicon wrote:

cro, did you file a request/bug report to the bugtracker?

No, not yet, I had no time and I'm unfamiliar with bug report stuff so far.

Last edited by cro (2009-12-23 20:37:03)

cro · 2009-12-27 00:59:40

I finally filed a feature request to split rubygems out of ruby.
http://bugs.archlinux.org/task/17611

Arch Linux

#1 2009-10-26 10:24:17

ruby 1.9 vs. rubygems

#2 2009-10-26 10:32:56

Re: ruby 1.9 vs. rubygems

#3 2009-10-26 15:17:49

Re: ruby 1.9 vs. rubygems

#4 2009-10-26 20:21:35

Re: ruby 1.9 vs. rubygems

#5 2009-11-16 19:24:30

Re: ruby 1.9 vs. rubygems

#6 2009-11-16 23:09:51

Re: ruby 1.9 vs. rubygems

#7 2009-11-17 02:46:26

Re: ruby 1.9 vs. rubygems

#8 2009-12-03 01:13:00

Re: ruby 1.9 vs. rubygems

#9 2009-12-03 01:23:53

Re: ruby 1.9 vs. rubygems

#10 2009-12-03 01:33:21

Re: ruby 1.9 vs. rubygems

#11 2009-12-03 04:31:32

Re: ruby 1.9 vs. rubygems

#12 2009-12-03 15:12:32

Re: ruby 1.9 vs. rubygems

#13 2009-12-04 02:02:51

Re: ruby 1.9 vs. rubygems

#14 2009-12-11 00:03:53

Re: ruby 1.9 vs. rubygems

#15 2009-12-19 11:31:48

Re: ruby 1.9 vs. rubygems

#16 2009-12-19 12:09:32

Re: ruby 1.9 vs. rubygems

#17 2009-12-23 20:36:44

Re: ruby 1.9 vs. rubygems

#18 2009-12-27 00:59:40

Re: ruby 1.9 vs. rubygems

Board footer