Arch is currently not ideal as a Ruby on Rails server

exis10z · 2010-06-01 12:33:39

kazuo wrote:

exis10z wrote:
I was just curious as to why the AUR packages couldn't be distributed as pacman packages, and why PKGBUILDs
Search the forum for the answer.

Sorry, I digressed a bit with that - I'll discuss it in that thread.

Allan · 2010-06-01 13:31:21

exis10z wrote:

If I look at the package statistics, Ruby actually seems to be very popular (in fact, more so than GIMP) .

Do not believe all statistics blindly. gvim pulls ruby as a dep and it is more likely that gvim is more popular that gimp...

exis10z wrote:

So I guess my question is, what's the best way to move forward with this? Could we consider changing the official version from 1.9.1 to 1.8.7 perhaps?

As I posted earlier, provide PKGBUILDs that allow ruby-19 and ruby-18 to install alongside each other more easily and if they seem reasonable, I will switch to using that for the official ruby (1.9) package.

A downgrade is unlikely... The number of angry emails I got when not upgrading to ruby 1.9.x was far higher than the number I got for upgrading to it.

tomk · 2010-06-01 14:18:28

exis10z wrote:

So I guess my question is, what's the best way to move forward with this?

Set up an arch-ruby repo - IMO.

exis10z · 2010-06-01 14:47:31

Allan wrote:

exis10z wrote:
If I look at the package statistics, Ruby actually seems to be very popular (in fact, more so than GIMP) .
Do not believe all statistics blindly. gvim pulls ruby as a dep and it is more likely that gvim is more popular that gimp...

gvim's 30% lower installs/usage wouldn't support that, and in any case, my point was that Ruby is installed by > 70% .. whether as a dependency or not, thus does warrant being maintained properly.
--

Is there a way to have both packages available via pacman and have them on a mutually exclusive basis i.e. the one conflicts with the other? Or can the architecture of arch packages not allow two packages to fulfill the same dependency?

In terms of servers, and the way the Rails stack is set up, it usually warrants just installing one or the other - depending on your app, gems, etc. Personally I'm not interested in setting up both at the same time, and I think heatdeath was implying this as well (please correct me otherwise).

Otherwise, I'll probably take the arch repo route as tomk suggested.

Thanks!

Last edited by exis10z (2010-06-01 14:48:58)

heatdeath · 2010-06-24 20:13:31

Nevermind.

Last edited by heatdeath (2010-06-24 21:58:54)

rddweb · 2010-07-24 20:45:54

I read all this topic, and agreed to the most part of the discussion. The problem is not with the ruby upstream. Ruby devs don't need to wait every app dev to make their code compatible with new releases to make their new rubies stable. But ruby 1.9, like some php releases, broke some things with older apps, that is natural, thats why they're recommending the 1.8 for production servers. Most of the major rails apps don't work yet.

I struggled a lot to make an ideal ruby installation on archlinux, since many apps don't work yet with ruby 1.9, and I wanted to test ruby 1.9, rails 3, etc, at same time.

I tried the RVM solution, but i followed the archlinux wiki to install it, like many of other things in my Arch box.

But the RVM article in wiki is simply wrong and outdated, despite the last update in july 3. I managed to install sucessfully after reading many docs, not only the wiki and the official RVM documentation.

I'll update the RVM article, since is the most easy approach to have ruby, rails and friends on ArchLinux, and even for production servers, since you can isolate the ruby + gems for every app you have, if you want to.

Hope this helps arch rubists here more confortable

Anikom15 · 2010-07-24 20:56:44

Isn't the most stable version of Python technically 3.x? Or does Arch have a policy on non-compatible versions? As for Ruby, the question has been delt with before, make your packages and if they get popular maybe a TU will take care of it for you. I've no doubt these packages could become popular considering all the Ruby fans in the favorite programming language thread.

rddweb · 2010-07-24 23:08:05

Yep, but the problem is neither with arch, neither with ruby. We are in gray area.

I'm already tried the ruby1.8 from AUR alongside with pacman ruby, and I had a lot of headaches.

To workaround this RVM fits perfectly. If you need to clean your system, just delete /usr/local/rvm and /usr/local/rvm and bye rvm.

I updated the rvm wiki article to make easier the installation.

For me the packaging of ruby can continue as it is now, because is the philosophy of arch. I like the KIS and top updated packages, but this comes with a pricing sometimes. I already dealt with this at php 5.3 release that broke some code and I managed gracefully because I had only a few code to change.

1.8 -> 1.9, as expected, broked a lot of things, but ruby comunnity have their own weapons to counter this, like rvm, bundler and so on... use it at will

Allan · 2010-07-24 23:22:00

Anikom15 wrote:

Isn't the most stable version of Python technically 3.x?

Yes it is... although the transition requires rebuilding ~11% of our repos. You will see this fun occur in about two or three weeks.

synthead · 2010-07-25 10:00:15

heatdeath wrote:

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.

Your idealist attitude is in the right place but for the wrong reasons. You've received the comments you've gotten because it's not in-line with the Arch philosophy. Let me explain:

AUR=Arch User Repository. These packages are made by users, uploaded by users, and the information on aur.archlinux.org is there as a resource, but to be used at your own risk. To integrate it fully with pacman would be a mistake. Imagine a malicious user that created a package for the AUR called firefox-optimized that had "build () { sudo rm / -rf }" in the build script, or post_install () { rm / -rf } in the install script. Anyone in front of an Arch system that thought the package was interesting would completely ruin their machine for good by installing it. This is why the AUR isn't and will never be officially supported.

As said, there is a handful of AUR helpers that make the AUR seamless. A recent addition is clyde. clyde -Sy kernel26 will download the 2.6 kernel from the official repositories, and the same command, clyde -Sy kernel26-crusoe, will download, compile, and install the unofficial kernel I made that emulates CPU instructions for a normally unsupported CPU. Likewise, clyde -Syu will upgrade every package to the latest, and clyde -Syu --aur will upgrade everything including any AUR packages. It seriously can't get easier than this for build scripts that can damage your system if you're not careful, and clyde will even prompt you to open the scripts up in an editor before you build them.

About bleeding-edge software: you probably won't have any old bugs, but you certainly will see new ones. If vlc gets a new version, but a bug in upstream causes vlc to not play mp3s, this is the version you are going to get with Arch. This is why Arch may not be the best option for servers. You are running into this with ruby. 1.9.x breaks things that worked on 1.8.x, so you need the old version. Rewind a little bit to where 1.9.x came out. In the bleeding-edge philosophy, you're getting 1.9 no matter what--it's the latest. If you want an old version, you need to make a package for it youself--hence why 1.8 is in the AUR.

However, this doesn't mean that Arch is bad for servers. The nice thing about Arch is that it's linux. It's not Ubuntu, Fedora, or any big-box corporate-style flavor, it's downright linux. When you install firefox, for example, you're downloading a binary of what was downloaded source code, a ./configure (with popular flags), a make, and make install (to an alternate destination for packaging reasons). We almost never badge anything, never change configurations (or even provide them sometimes), or anything. You want a package? You get the latest version, as bland as it gets. If you were to download everything from developers' websites, configure, make, and make install to a working system, you would get damn close to an Arch Linux default installation minus the kernel, and a .config file and a few patches later, you would have the Arch Kernel too.

What I'm trying to say with the previous paragraph is that Arch can be made to be whatever you want. You can make it run on unsupported CPUs or even switch to a different package manager if you have a good enough idea about what you're doing. In your case, the best thing to do would be to run a local repository of packages that you know are stable. You could even see what another distro is doing, perhaps a stability-minded one like Debian, and copy the versions, configure and make flags, and patches. In fact, you could even download and repack apt sources for your local repo. This is a lot of work, however, so the easiest thing to do would be to just create a server, know it works, and host the packages you used for the installation on a local repo. When you've tested new packages enough on a test server, you can move those new packages to the local repo and sync.

The users here are suggesting that you use another distro because you don't need to worry about stability so much (even though you will be using dated packages). Every distro has its ups and downs, so use what's best for you. Personally, I love pacman's power and simplicity, so once you get in the rhythm of things, I'm sure keeping an extra stable Arch system up won't be difficult. I run into problems with a pacman -Syu less than 1% of the time.

Edit - I understand where you are coming from btw. I run Arch on all my machines and work for a medical databasing company that relies on RoR 1.8 for about 70 EMR servers. We need 1.8, but any instability is not an option.

Edit #2 - You might be interested in this: http://www.rubyenterpriseedition.com/ Take your time to install one more package from the AUR, clyde, then install it by running clyde -S ruby-enterprise.

Last edited by synthead (2010-07-25 10:11:27)

Arch Linux

#26 2010-06-01 12:33:39

Re: Arch is currently not ideal as a Ruby on Rails server

#27 2010-06-01 13:31:21

Re: Arch is currently not ideal as a Ruby on Rails server

#28 2010-06-01 14:18:28

Re: Arch is currently not ideal as a Ruby on Rails server

#29 2010-06-01 14:47:31

Re: Arch is currently not ideal as a Ruby on Rails server

#30 2010-06-24 20:13:31

Re: Arch is currently not ideal as a Ruby on Rails server

#31 2010-07-24 20:45:54

Re: Arch is currently not ideal as a Ruby on Rails server

#32 2010-07-24 20:56:44

Re: Arch is currently not ideal as a Ruby on Rails server

#33 2010-07-24 23:08:05

Re: Arch is currently not ideal as a Ruby on Rails server

#34 2010-07-24 23:22:00

Re: Arch is currently not ideal as a Ruby on Rails server

#35 2010-07-25 10:00:15

Re: Arch is currently not ideal as a Ruby on Rails server

Board footer