I was wondering: when installing something, there's an easy way of double clicking an install executable file, and on the other hand, there is a way of building it from source.

The latter one, downloading a source bundle, is really cumbersome.

But what is the fundamental difference between these two methods?


5 Answers 5


All software are programs, which are also called source packages. So all source packages need to be built first, to run on your system.

The binary packages are one that are already build from source by someone with general features and parameters provided in the software so that a large number of users can install and use it.

Binary packages are easy to install.
But may not have all options from the upstream package.

So for installing from source, you need to build the source code yourself. That means you need to take care of the dependencies yourself. Also you need to be aware of all the features of the package so that you can build it accordingly.

Advantages of installing from source:

  • You can install the latest version and can always stay updated, whether it be a security patch or a new feature.
  • Allows you to trim down the features while installing so as to suit your needs.
  • Similarly you can add some features which may not be provided in the binary.
  • Install it in a location you wish.
  • In case of some software you may provide your hardware specific info for a suitable installation.

In short installing from source gives you heavy customization option at the same time it takes a lot of effort, while installation from binary is easier but you may not be able to customize as you wish.

Update: Adding the argument related to security in the comments below. Yes it is true that while installing from binary you don't have the integrity of the source code. But then it depends as to where you have got the binary from. There are lots of trusted sources from where you can get the binary of any new project, the only negative is the time. It may take some time for the binary of the updates or even a new project to appear in our trusted repositories.

And above all things, about software security, I'd like to highlight this hilarious page at bell-labs provided by Joe in the below comments.

  • 5
    source also can be compiled in an optimised way for your system (which.. may not be a good idea, as then the compiled stuff is "specific" to the system and may not work on a backup one... but you have the source, you can recompile (if you have time for that)) Aug 27, 2014 at 9:44
  • This depends on if you have that "backup system" at all. If you are just doing some research, you typically do not.
    – h22
    Aug 27, 2014 at 13:02
  • 2
    For the hyperparanoid, one advantage of installing from source is security and the ability to review the code if you are able to and or want to: when you install from source, you know for a fact you have a binary from that source code and not a binary with unknown modifications (assuming you trust the source in the first place).
    – LawrenceC
    Aug 28, 2014 at 12:31
  • 8
    @ultrasawblade - You're obviously not paranoid enough! <G> - see cm.bell-labs.com/who/ken/trust.html for the full monty.
    – Joe
    Aug 30, 2014 at 5:15

A source file contains the original code as written by the developer in whatever language he/she chooses (C, C++, Python etc),and is generic. It isn't specific to any distro and in many cases to any operating system.

A package (RPM or DEB for example) is the binary executable (or interpreted script etc) pre-prepared for your particular distro. The task of preparing the source for compiling (adding any necessary patches etc), the actual compile, creating distro specific config files, creating pre and post install scripts etc are all done for you by the package maintainer.

In other words, all the donkey work has been done for you in a package, whereas you'll need to do it yourself if you choose to install from source.

It is much easier to use a package in nearly all cases as:

  • They are much easier to install
  • They are specifically designed to work with your distro
  • They are sometimes patched by the package maintainer to fix distro specific bugs
  • The package manager will uninstall them
  • The package manager will manage all dependencies for you
  • The package manager will take care of updates
  • You don't need to install developer tools on your system (compilers, make etc)

However, sometimes the packaged version is an old version or even worse, there is no packaged version; in which case your only option is to compile yourself. If you do, you need to consider the following:

  • You'll need to install all the developer tools on your system
  • You will be responsible for checking for an update and recompiling
  • You will need to make sure all the dependencies are installed, including dev packages - there could be many of them.
  • You may need to debug problems if it doesn't work as expected on your distro

If you are willing to put in the extra effort, then compiling from source may give you the benefits of:

  • Access to the latest available version
  • The option of optimizing the compiling process for performance/stability
  • Enjoyment!

Note that while some distros' pre-built packages provide binary executables which are ready to install and run (RPM and DEB are examples), other distros provide packages that simply automate the process of compiling.

Gentoo's ebuilds is an example of this - the package is basically instructions to the package manager describing how to compile and install the executable. This has many of the advantage of traditional package managers (automatic updates, uninstalling etc) while still allowing the user to optimize the compiling process to his/her taste.

Arch Linux has a packaging system where the mainstream packages are binary while many extra packages are compiled on the system using PKGBUILD files.


Apart from the other answers, I would like to add something:

If you decide to compile a program by yourself, you need to think that compiling is not something you do only once. You will probably need to subscribe to the development mailing list of the applications you decided to compile and stay up to date with the new versions and, especially, the security updates.

Every time the application is updated you will have to recompile the new version so, just keep in mind that you will have to spare some of your time every week.

If you cannot afford that, it is better to let the package maintainer do that job for you.


Building from the source allows to specify architecture of exactly your machine. New CPUs have additional instructions that compilers do understand, squeezing out a little bit of performance. Pre-build packages usually count on the most archaic CPU still in common use.

This is mostly important for project-critical applications that use CPU very heavily, such as tools of bioinformatical pipeline, for instance, or geophysical modelling tools. Such software runs in a very controlled environment, does not feature access control on its own, so seldom has security bugs so urgent that they must be patched in days or hours. Almost never it needs to run on a different machine with initially unknown architecture.

Yes, I known, computers are very very very fast now and any efforts or actions you take are very very very expensive, but on the third day of sitting and waiting your program to complete (this is the situation I am talking about) such truths start looking questionable.

Differently, applications like browsers and the like should be better used from the maintainer repository (and not from some downloaded pre-built packages), as it is very important to keep them up to date.

  • Where such tweaks to exploit your CPU to the fullest do make a difference (this is relevant only in some very specialized code; the saying is that 95% of the time is spent on 5% of the code, so that optimizing the other 95% makes no noticeable difference; and most of today's programs are 99% of the time waiting for the user to make up their mind anyway), programs offer different code to be switched on depending on CPU on startup.
    – vonbrand
    Feb 29, 2016 at 13:27

One way to get the best of both worlds (up to date software, simple install/uninstall, incorporate most distribution tweaks and adaptations, can optimize for local requirements), while the costs (have to keep up to date yourself, watch out for bugs and last-minute patches, follow development, you are on your own with respect to bug fixes and incompatibilities between versions) can't be mitigated (much), is to build your own packages, starting with the source packages from your distribution. I.e., unpack the source package from your distribution, replace the source with the upstream version, check if any of the distribution's patches or configuration tweaks still apply, build the binary package (make sure you changed the version of the packaged stuff!) and install that one. Yes, it is more work than just building and installing.

  • 2
    It seems like an interesting answer ("best of both world"), but I can't quite understand what you mean here: "is to build your own packages, starting with the source packages from your distribution". Would you mind rewording / explaining? Dec 6, 2017 at 9:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .