Source vs Package Managers on the job

I am a bit confused, as there are two ways to install applications. One being to configure and make from source and the other from a package manager. If one were a UNIX/Linux administrator, is it fair to use package managers and is it trustworthy? I have come across a few places, which seems to say today's admins really don't know what they are doing, because they don't do things from scratch and instead prefer package management.

So as an aspiring UNIX admin, I know I should know both methoods and I do, but which should one choose first. As an example, on a job interview if asked to set up Apache, does one reach for the source or the package manager?


I always go for the package manager first. However, instances where I compile from source:

  • The package is woefully out of date. This is more common than it should be.
  • I want to install to a different location than the package defaults. I do this a lot on my Amazon EC2 instances so I can install to my EBS device rather than ephemeral, local storage.
  • The app needs to be compiled using different options or with a source patch. PHP is the most common culprit here.
  • The app is a dependency of something else you want to install and your package manager doesn't have a matching headers/development package. Not all that common, but it does happen from time-to-time.

As a system admin should you know how to deal with source...sure. In a production environment is it advisable to use packages from source. I would say only under certain situations where the distro's version doesn't support your requirements.

The problem with source is that you are then responsible for making sure that you apply any security patches to the code for the application and any library it relies on. Or you have to continually version bump to stay with the latest secure code which isn't a good option for a production server most of the time. While a distro will back port security patches to the version they support for many years. So simply by telling your package manager to update the system will keep it up to date with security patches. This is much more manageable in the long run.

As a system admin you also have to think about who comes behind you. Inheriting a system with a mishmash of source packages is not much fun and will cost the company more money in the long run.


I have come across a few places, which seems to say today's admins really don't know what they are doing, because they don't do things from scratch and instead prefer package management.

I believe that this statement is not accurate. Surely, a system administrator has to know how to compile from source, and it is very rare that one has not done it at least once.

However, as everything in life, deciding which method one should use, is based on one's requirements:

1) If the official distribution's package versions cover your needs for features, then the answer is clear: Use the package system. There is no excuse to the ease the package system provides. It installs automatically all dependencies, and your work is limited in the configuration files. Most famous distributions (Redhat, Centos, debian) keep the official packages constantly updated, since they backport all security patches, and you don't have to worry about security updates, since they can be updated automatically. This is very useful in a production server, since you spend your time in system administration, auditing etc, rather than constantly checking if a package has a new update.

2) If your project needs the latest features that only the latest versions - of the applications you need - provide, then you have to compile everything from source. It is time consuming, and you have to constantly monitor if a new version gets out with security bugs. Then you have to recompile everything. The disadvantage is clear. However the problem is bigger if you have to administer more than 1 server. In this case the easiest way is to build a repository of your own, build your own packages based on the source code of the latest version, and then use again the package manager on each server to update the packages using your repository.