Install software on CentOS: binaries or rpm?

I am pretty new to linux systems. I have the option of installing a software (ImageMagick) using either its .rpm or compiling the source from .tar.gz (which I have already done).

  1. Which one should I (would you) choose?

  2. If I choose rpm, should I use rpm -Uvh <filename> or use yum to install the rpm?

  3. If I choose to install the binaries, what is the usual way of installing (for use by Apache/httpd)? I am thinking I should download the .tar.gz file to /usr/local/src, unpack it with tar zxvf <filename>, then ./configure, make, make install. Generally if I do this, will the binaries automatically go to like /usr/bin (it does for ImageMagick) and the environmental paths be set for all users?


Which one should I (would you) choose?

Use RPMs and stick with RPMs. RPMs are far simpler to use then sourcecode, are easier to update and install security updates, and will will save you time in the long term. I can update all software on my CentOS box in about 5 minutes. It would take hours and hours, perhaps days, to do the same thing when compiling from source.

In addition, since you are new to Linux systems you will want your system to be in line with what the rest of the community uses, so that examples in documentation and forum posts will match what you have available on your local system. The documentation usually assumes that you installed software via RPM. If you have a hybrid system which is built from RPM, but then have a dozen programs installed from sourcecode, debugging will be more difficult and will require more knowledge and skill.

Compiling from source is more complicated and will require you to resolve dependency issues during the compilation. Before you can compile software, you will need to install dependencies such as header files, compilers on the system, and these are often installed via RPM anyways.

However, note that RHEL and CentOS generally stick with one major version of a product (e.g. CentOS5 provides an RPM for PHP 5.3, but will never provide an RPM for 5.4). Security fixes and some feature changes are 'backported' by RedHat into the current version.

Install from source if you want a particular version of the software which is not available from CentOS or if you want to customize the source code by yourself. For starters, try to avoid this.

For ImageMagick, install the RPM provided by CentOS. If it doesn't meet your needs, then research which version you need, and install it from source.

rpm -Uvh or use yum

Use yum, which is a wrapper around RPM (the RPM libraries) and does much of the work for you. Again, this will save you time.

RPM is used to install an RPM from a local file, which means you will need to find the RPM and download it and all of it's dependencies. Yum will perform dependency checking, and will download and install the RPM for you.

will the binaries automatically go to like /usr/bin

I prefer it when sourcecode puts the binaries in /usr/local/bin and not /usr/bin . /usr/bin is for software provided by the vendor, and /usr/local/bin should be reserved for locally compiled packages. If the sourcecode installs the binaries to /usr/bin , it means that those binaries may get accidentally replaced next time you run yum update --yes.

Also see https://unix.stackexchange.com/questions/8656/usr-bin-vs-usr-local-bin-on-linux

There are other Unix variants which compile all of the software from source, but those systems tend to have good methods and good tools to keep all of those source files organized. FreeBSD is a popular operating system where admins tend to compile software from source packages called 'Ports', and it is a great way to learn about OS and sourcecode.


  • I try to stick to the distribution packages as much as possible. It tends to be a more consistent approach to software management. If you find items that are not available as RPM packages, you can build your own RPM's from source tarballs.

  • If you choose RPM, using yum is a means of pulling software from a software repository and installing via RPM. RPM is the actual package manager framework.