Arch is currently not ideal as a Ruby on Rails server

Question

Hi all.  This is my first post.  I hope I am posting in the right place.  I have just started using Arch, and I love it!  I have used many server distros in the past, have real experience in production environments, and I'd love to use Arch for any servers I need in the future.
There's a problem, though.  Best as I can tell, the only version of Ruby available on Arch right now is version 1.9.1.  While that's the latest stable, for certain reasons it is not the recommended version on which to run the popular web framework, Ruby on Rails, which I make my living developing in.  You can see that for yourself here:
http://rubyonrails.org/download - "We recommend Ruby 1.8.7 for use with Rails."
I'm sure this isn't the first time there have been popular versions of software despite there being later releases.  People are often slow to adapt in production environments.  However, I couldn't even find a ruby18 package, or anything like that.
I'm not requesting years-old stability or anything absurd like that.  In general, I like having the newest software.  But in practice, it's sometimes prudent to prefer the next-to-newest software.
In addition, the ruby package installs "rubygems", a separate package management system for Ruby analogous to CPAN in Perl.  The problem is, it installs an old version of rubygems, 1.3.1, which is so old it doesn't work.  The latest stable version of this is 1.3.7, and version 1.3.2 is required for Rails.  I was able to upgrade it using the special rubygems updater ("gem update --system") but I worry this will conflict with pacman, and it shouldn't be necessary.
In short: please upgrade rubygems, and please provide a 1.8 version of the ruby package.
All of the packages I'm discussing were based on the present pacman versions as of this post.  Thanks for your help and for the great distro!
Last edited by heatdeath (2010-05-31 04:27:58)

Answer 1

tomk wrote:heatdeath - you're not getting the point. If there is something you want from Arch that is not available in the official packages, you become part of the community and do it yourself. It may end up being just for you, or others may also find it useful and help you out, but either way you get what you want, and Arch gets the "community support which it does not have". There have been numerous examples of this over the years.
I understand your point, but using the AUR dramatically diminishes the ease of use from the whole setup.  I have to manually download the PKGBUILD and any patch files, build it, install it, and then manually keep track of updates, manually delete the installed files (there is no uninstall) and then repeat the process.  While it's great that the AUR is there for specialized interests, it seems that things from the AUR should be incorporated into the official packages if they have enough support.  My problem is mainly in the selection of "official packages", and the deference to the AUR anything that doesn't meet the strict and dare I say impractical requirements for inclusion therein.  There needs to be more respect for widely-used earlier branches, and there needs to be respect for upstream packaging problems such as the rubygems one.  And I am here, in the community, voicing my opinion on this issue, but I cannot change the official packages or the philosophy by sheer force of individual will.  It's going to require that people consider what I have to say, and consider what Arch should be.
Ruby 1.8, as with many other major releases, continued in its development and had point releases even after Ruby 1.9 came out.  Despite being official, these releases are not available via pacman.  It remains the dominant form of Ruby in use today, and probably will be for another year or so.
Consider the release of MySQL 5.0.  Would you expect everyone to switch from 4.1 immediately to 5.0 once they released their first stable?  Or shouldn't it be possible to stay on the prior major version branch and make the conscious decision to switch?  At some point, the keyword "mysql" should switch to the newer branch, and the old one should be maintained as mysql4.1 for legacy support for a while; but this should be a while in, after the tide has turned in its favor.  I'm certain something like this is already the policy for the Linux kernel, for instance.  I'm just asking it also be applied to Ruby.
Instead, I'm relegated as a minority interest to the AUR ghetto.  I think Rails and its philosophy has a lot in common with Arch Linux, and I've heard other Rails people speaking of it favorably.  They are both focused on ease of use.  They could be compatriots, and Arch could benefit from the friendship.  Both communities are often interested in using brand new software, when appropriate.  Rails is ruthless with its deprecation.  But the community for Arch Linux needs to decide whether it can be useful as a young, innovative new server distro for practical use, or whether it's beleaguered by the philosophy that "true" "critical" server distros use "stable" archaic software and sacrifice maintainability, bug fixes, new features, and simple pleasure in the process, and therefore Arch has no place amongst their anachronistic pantheon, doomed to dwell underground forever with Gentoo and the other thoughtful playthings.
I was surprised to find myself being criticized for suggesting I would use Arch as a production server.  I think it has the chops, it just needs to commit to the purpose.  Don't be defeatist, there are a wide variety of possible production scenarios, many which use fresh new software; let server admins make the decision whether or not Arch is capable of the job.
As for variations on upstream releases (such as fixing this rubygems version problem), I think the best solution is that pacman should have something that allows automatic building, installing, upgrading and uninstalling of community packages -- maybe even binary variants -- so that users can have the ease of use, but also realize they are using something that differs from the official upstream releases.  A convention to install in /opt or /usr/local/ would further the mental divide and diminish the risk.
Please understand my criticism comes with respect, and a desire to use Arch.  I ache every time I check the replies, knowing I've likely offended people.  I apologize for the length of this post.  The truth is, if I can't use Arch as a production server, I don't see any point to it.  I am an outsider looking in, sharing my thoughts, and I don't expect they will be received warmly, but it would be great if they were.  However, so far the impression I get from this thread is that Arch has no interest in being a production server, sees it as a sideline, implausible interest in conflict with its theory.