Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Usually I use apt-get but apt-get can get out of date.

It seems that quite a nice solution may be to get the source code for my software (for example, nginx) from github and then build it each time.

Is there any reason why this may not be a good idea?

In my mind it means I have the most up to date code each time including the latest bug fixes.

share|improve this question
It also means you are checking out non-production code into a production server. Why don't you use a sprint every 4 months to handle tasks like this. – Ramhound May 9 '13 at 12:00
"In my mind it means I have the most up to date code each time including the latest bug fixes." <- But you also have the latest bugs that way. – us2012 May 9 '13 at 12:58
This also depends on the project your cloning from github. Some projects do all their development in a development branch with the master branch only being updated with major, stable releases. – FSMaxB May 9 '13 at 15:33
up vote 3 down vote accepted

It all depends how critical your production system is. Can you afford down time if changes in the way the downloaded version works cause an issue with your system? The latest version of the software may have a bug or bugs which were not in the previous version. Or side-effects of the latest version may affect your system - perhaps in a subtle way that is difficult to identify and correct.

Introducing new software in this way is risky. Yes it is tempting to keep up-to-date with the latest software. The opposing strategy of not updating software can result in systems with software running from ten or even twenty years ago. This does actually happen with real production systems.

Downloading the software to a test system which mirrors the production system and then applying a full suite of testing before considering applying the changes to production would be a safer practice. Automated testing can help with the burden of testing an entire system. Of course, that can be a substantial effort. It's a trade-off between the importance of maintaining reliable service and the resources required to assure those concerned the system will be safe if the changes are applied.

share|improve this answer

First you should look around, you might find a ppa having the new version. That is the easiest way.

In the case there isn't:

Building and installing software from source can lead to messed up libraries or binaries on the system, as another package might overwrite something or vice-versa.

To avoid this, there are 2 solutions:

  1. Only build the source, and use the binaries locally, but this means you have to write your own init or upstart service for it, if you want to handle them properly.
  2. In my opinion the best: Get the repository version of source code with apt-get source, overwrite it with the new source, and build it the debian way. There is a quite good tutorial on package building here. The only drawback is, if there is some change in the building process, you have to make the changes in the debian scripts too.

You should also consider, that a new version might depend on a newer library than your repository has. In this case you might find a ppa of a newer build, or you should build one yourself with the same way, but this can be a quite long process, walking through all the dependencies.

In short, if you are luck you may get through this fairly quick and easy. If you are not, then you are better using your distro's version.

share|improve this answer

Your Answer


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.