Install software from packages, or build it from source?

You should use your distribution's packages unless you have a good reason not to. Using the distro's packages gives you important benefits:

• It's less work to install and uninstall the packages, and keep them up to date.
• The packaging system will automatically install the software's dependencies, and keep them up to date too.
• Security updates are provided automatically for you by the distro, so you don't have to track them or worry about missing them.
• The packaging system will configure things in your distro's preferred way. For example, on apt-based systems, Apache comes installed with symbolic links in /etc/apache2/*-enabled, and tools (a2enconf, a2enmod, ...) to use them to enable or disable features of Apache. While initially that may take more work for you to learn, in the long run your life will be easier and your configuration will be better integrated if you use the distro's native tools and ways of doing things.

If you need to use a newer version of some software than your distribution provides, or enable a feature that has to be compiled in, you may be able to find more up-to-date or featureful versions of the package from community repositories. Remi's repos are a well-known example, offering among other things much more up-to-date versions of PHP than those that ship with RHEL/CentOS. Using a community repository gets you many of the advantages of the OS repos, but at the risk that the author is releasing malware which you then install, with full privilege, onto your system. You will have to make the risk/reward judgement yourself, on a case-by-case basis.

If neither of those alternatives works for you, you will need to compile from source. When compiling software from source code, the recommended route is to create your own binary packages. Building your own packages allows you to:

• Work with your distribution's package management system for distribution, installation, dependency management, reporting, upgrades, downgrades and removal.
• Restrict your build tools and development libraries to a single build host (rather than installing them on all test and production servers).
• Follow the common release path of first deploying your packages in a test environment before deploying that same package in your production environment.

Since that makes you the package maintainer, you will need to subscribe to the relevant security mailing lists so you won't miss any critical bugs and security updates.

If you do end up installing locally-built software without packaging it, GNU stow can help to keep it well organized and make it easier to cleanly uninstall.

I like Andrew's response.

I want to point out a specific to add on to Andrew's comment about "better integration." If you install an application from source (a dependency of a future project), and later try to install a package from a binary (e.g., a deb or rpm package), that package may not recognize that a dependency is installed. Had you installed the initial dependency application from an RPM or DEB package, the future package would know it was installed. Using the same package method (e.g., yum, pip, rpm, etc.) is a best practice. Installing from source is yet another method. So the ease Andrew is talking about is a serious consideration.

I want to add that "create your own binary packages" has a benefit of logging the installation process. Installing from source files doesn't have the benefit of logging.