0

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--
Roman Shtylman
  • 101

2 Answers2

1

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: https://help.ubuntu.com/community/PinningHowto

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).

1

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...

Ilia K.
  • 176
  • 2
  • 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