On 5/16/07, Jeff Abbott <[EMAIL PROTECTED]> wrote: > I dislike managing Rails with gems on systems with package management.
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. Ruby world has chosen RubyGems. You can fight it, or roll with it. For something like RubyWorks, "roll with it" is arguably the only reasonable path. 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. 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. -- 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 -~----------~----~----~----~------~----~------~--~---
