On 5/16/07, Jeff Abbott <[EMAIL PROTECTED]> 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.
> If all you're looking to do, though, is cover Rails and Mongrel, > that's not that difficult; I've done it. We will be repackaging Mongrel as an RPM, because it's basically part of the hosting infrastructure. Not Rails, however. Rails belongs in your_app/vendor/rails. > > The need to have gcc and header files on production boxes > 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. I'll look at that. Thanks. > 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! I specifically asked everybody to tell me what sucks. :) > 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. :-) Almost. We have a slightly different conversation in mind. Q: "As an overworked sysadmin managing this zoo of COBOL, Java and .NET applications, how do I host this shiny new Rails thingie development is pushing down my throat?" A: "create some virtual machines, load up this yum repo and read this document. By the way, here is a phone number to call if you run into problems." The underlying idea is same though. Rails production deployment should not be a pain in the butt. Nor should it require reading blogs for two weeks, trying to figure out what's the best deployment practice du jour. -- Alex --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
