Where should I draw the line between using apt-get and gem when setting up a server to host ruby on rails with passenger + apache?
Does it even matter?
It feels wrong to mix package management systems when considering software updates and so on.
How should one go about this?
One thing to keep in mind is that updates will happen much faster using gem than they will to the official apt repositories. Perhaps there are third party repositories that are more up-to-date, I'm not sure. However, my impression is that if you need bleeding-edge newness, then update using gem.
I don't use apt-get, as I run NetBSD, but "pkgsrc" has a similar role as apt-get.
My local policy is very simple. If I can use a gem, I use a gem. If I cannot, I get it from pkgsrc. Some things which require native code (sqlite, a few others) simply do not reliably install as gems out of the box.
The major benefit I see to using a gem for most things is that I can have more than one version installed at once. For instance, I have 3 different version of Rails installed, and applications can be slowly migrated from one to another.
I'm not certain if apt-get would let you do this, but I know pkgsrc does not. It's a feature I need and use.
Our policy is that we use gems when there's no debs "downstream" in the dependency chain (so usually customer-deployed and managed code), but everything we do ourselves is packaged properly and so we'll roll any dependent gems into debs to satisfy those dependencies. The different packaging systems shouldn't be a problem; your system management automation tool should be capable of handling the differences gracefully.
I draw the line in the sand at updates quick vs stable is ok
Example I deploy on hardy, if Ruby 1.8.6 is acceptable, otherwise, the latest released Ubuntu if I need 1.8.7
I then install the rubygems tarball as you need the close to latest version for Rails 2.3.4, and then install passenger etc using gems.
Situations such as rmagick where you need to have imagemagick installed, I use the system debs for imagemagick and then install the rmagick gem
«Where should I draw the line between using apt-get and gem when setting up a server to host ruby on rails with passenger + apache? Does it even matter? It feels wrong to mix package management systems when considering software updates and so on.»
Note that APT (of which 'apt-get' is part) is not a package manager, it is a dependency manager. This is very important; the package manager is DPKG.
Now the rule is that a set of directories should contain only a set of packages managed by a single package manager, or else very bad things will happen (e.g. a package managed by one will be partially overwritten without warning by a package managed by another).
RubyGem is a package manager like DPKG, or like Perl's CPAN or Python's EasyInstall downloaders, and they should never be mixed with other package managers, including DPKG.
«The major benefit I see to using a gem for most things is that I can have more than one version installed at once.»
That DPKG cannot have different versions or different platforms of the same package installed is a very grave and bad limitation, which has made Debian create extremely ugly and poor workarounds (encoding version and platform in the package name itself). Unfortunately those who choose to use DPKG have to live with that limitation.
In case it was not clear from my previous reply:
«It feels wrong to mix package management systems»
It is indeed wrong to mix them in the same subtree. if you install two package management systemsn (e.g. DPKG and RubyGems) by giving them different subtrees, that is going to be fine. That's why '/usr/local' is a separate subtree and '/opt' is another separate subtree. RubyGems by default uses '/usr/local/lib/ruby' which seems plausible to me (and does not conflict with DPKG, but may conflict with manually installed packages).
«have more than one version installed at once.»
If that is a requirement, then use RubyGems in a separate subtree as mentioned above. DPKG as you figured out simply cannot do it in any decent way. The comparison here is between RubyGems and DPKG, not with RPM, which was never mentioned in your question or in my previous answer, even if some Debianistas seem to have an inferiority complex about RPM.
Having multiple versions of a library or application is a very important feature, especially for testing vs. production use, and especially for web apps, so I would recommend RubyGems and not using debgems.org at all.
It's probably one of those questions where you'd see 50/50 divide. Maybe you should define your criteria more precise to get a useful answer.
In my experience all *nix based package managers like ports, macports, rpms, dpkgs, etc. have rather strange inter-dependencies, and often install stuff that you don't want or don't need for your task, or don't install what you do need. I don't see the same pattern with gems or CPAN packages.
