Alexey Verkhovsky wrote: > Having to deal with two package managers is a bit awkward, indeed. > But... repackaging however many gems there are at the RubyForge > repository as RPMs is an insane amount of work. That is the problem.
It would be quite difficult to package up gem, to the point where I wouldn't even try without some sort of automated method (say, "gem rpm foo"). If all you're looking to do, though, is cover Rails and Mongrel, that's not that difficult; I've done it. > Using private package repositories for staged deployment is quite > obviously The Right Way (TM) in many scenarios, so we will be > addressing that in near future. One can do that with gem repositories > just as easily as with yum. That's good, and is an architectural feature that has paid off heavily for us since all we need to do to move a set of Rails packages to production is copy the files over and re-build the repo. > By the way, there is another issue with RubyGems that I'm aware of. > The need to have gcc and header files on production boxes (for > building native extensions). Not every Linux admin likes that. So far, > we are demanding it (our rubygems RPM has a dependency on gcc and > ruby-devel), but I would appreciate it if someone could suggest > another way. This is another problem I encountered, and one that also was able to be resolved in our environment by repackaging gems. Since we don't have any compilers or headers on our production systems, which is frightfully easy to do with any package-based distribution, and we aren't going to install them just for gems, having the packages built on a build machine in a build environment (using Mock -- http://fedoraproject.org/wiki/Projects/Mock) we can get consistent results for all our systems. The biggest hassle so far has been Ruby's multilib support (or the lack thereof), requiring us to build and maintain separate i386 and x86_64 packages for the appropriate /usr/lib/ruby or /usr/lib64/ruby directories, but I've heard that should be improving shortly, allowing us to build noarch packages, which is what they should be. Please don't misunderstand me as slighting your work at all, either! One of my ideals is that people ask, "What's the best OS or distribution to run a Rails server with," and we could reply, "CentOS, and then load up this yum repo." I'm pretty sure we're both on the same page with that. :-) Thanks, Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
