Server Fault is a question and answer site for system and network administrators. 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

The basic goal I am aiming for is to be able to support older binaries and libraries in a production environment while still moving forward with newer libraries and binaries.

Infrastructure setup:

  • Ubuntu Linux
  • Use debian packages of the relevant libraries
  • c++ shared libraries

Reasons we want to keep multiple versions:

  • Move production jobs over to new libraries piecewise
  • When underlying c++ boost libraries change, the dependent libraries should be recompiled against the new boost versions
  • Don't want library dependencies changing for a single production release--
share|improve this question

AFAIK the best practice is to create local repositories mirroring the oficial ones and, on your sync script, exclude the packages that you don't want to update.

Also you could use Pinning:

But, on the other hand after release distros usually don't change versions of packages. They just put security fixes, but keeping the same version.

So, as far as you don't change from ubuntu 10.04 to 10.10 your binaries and libs should stay on the same versions. (this for oficial packages, if you are building your own packages, create a local repository with them and check the documentation about .deb repositories because the repo it self is able to do some kind of versioning).

share|improve this answer

Generally, two versions of the same package supply the same file(s), and you can't have two different files with exactly the same path... unless you trick the application. One way to trick the application is to run it inside chroot environment. You can mount --bind and ln most of the stuff from the original filesystem to save HDD space. IMHO the most convenient way to systematically run applications inside chroot is schroot. Just apt-get install schroot under Debian/Ubuntu and then read the manual.

A more powerful (but more tricky to setup) solution is to use container, such as LXC which can provide "virtualized" view of file system (among many other things). Probably, this is an overkill for your situation.

Grr, I can't post links with so small reputation...

share|improve this answer
How would you go about managing deployment and configuration of these systems? They aren't like virtual machines that are always running. Also, you would need to maintain multiple repositories for the different flavors or something along those lines, because you would need to build packages relative to their environment. – Roman Shtylman Oct 28 '10 at 18:17
I'm running several chroot environments using schroot. In the common case all you need is just schroot -c CHROOTNAME -u root and you get a normal root shell inside the chroot. CHROOTNAME is what you've configured under /etc/schroot/chroot.d/. – Ilia K. Oct 29 '10 at 22:40

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.