Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

8 Answers

up vote 4 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Generally the "downsteam" debs are too old to meet the requirements anyway. –  rodjek Dec 30 '09 at 12:59
add comment

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

share|improve this answer
add comment

Building debs from gems can be automated. Python, OCaml, Cabal and CPAN packages are straightforward. debgem is a gem-to-deb service with 25k packages, but it seems it didn't take off and lags a few rails releases.

share|improve this answer
add comment

«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.

share|improve this answer
    
I don't think the question was: is dpkg better or worse than rpm? –  ℝaphink Dec 30 '09 at 21:29
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.