1

When I build binaries from source provided by a third party, there is pretty much always an issue with the dependencies versions.

I mostly use Debian (Sometimes Ubuntu) and the repositories only have one or two major versions, so I am unable to get the version the source requires.

Normally, I do one of the following:

  • Manage to get the version I need from apt-get (Rare)

  • Change the sources.list and just update that one package (which seems to break other packages and there dependencies)

  • Do a dist-upgrade (software I have compiled before stops working, as older dependencies are being replaced with newer ones)

  • Attempt to install the dependencies without aptitude directly from the third party’s website

For example source requires g++5, Debian Jessie only has 4 in their repository or installing a shared library such as libboost.

What is the best way to manage dependencies that are not available with the current distributions aptitude source?

Vlastimil Burián
  • 28,462
mt025
  • 121
  • 3

1 Answers1

3

TL;DR: use /usr/local, or backports, and package your own software.

I’ll start with a generality: a distribution release is a coherent unit. Obviously it exists to support what its users want to do on top of it, within reason (see item 4 in the Debian social contract), but it first has to support itself; in particular, the libraries it contains are there primarily because they’re dependencies of some other piece of software in the distribution, and the -dev packages (or devel for readers on the RPM side of the fence) are there so that the packaged software can be built using the distribution. When you’re building software on top of a distribution, if the libraries included in the distribution meet your requirements, that’s great, and you’re very welcome to use them; but if they don’t, you should avoid massaging the distribution to upgrade them.

Some development environments deal with this already: Python has its virtual environments, Ruby has something similar, Java and NPM manage their own project-specific dependency trees, etc. The C/C++ ecosystem doesn’t really have anything like this, apart from /usr/local, which might well fit the bill in many cases, including when the compiler is too old.

In practice, in the C/C++ ecosystem, there are a few viable solutions.

  • If you need the bleeding edge, you can use an “unstable” system for your development. It doesn’t have to be your full system (you should only do that if you’re comfortable helping Debian develop its next release), a chroot works very well for this; also note that “unstable” refers to the ABI stability, not the general stability of the system.

  • If you’re comfortable managing your own dependencies manually, build your software and its dependencies (which aren’t available in the distribution) in /usr/local (and check out tools such as Stow to manage versions).

  • If you just need a few upgraded dependencies, consider using backports. This answer will explain how to go about installing backports and even building your own; this will allow you to continue using packages in a safe way with newer versions than what you can find in the current stable release. This does scale quite well, and many organisations maintain their own repositories of backported packages internally.

Above all, it’s worth learning to package the software you’re building: doing this means that the distribution’s tools will help you ensure the dependencies remain available, which is very useful when you install your software on other systems, and when you upgrade. Vincent Bernat’s excellent pragmatic Debian packaging technique will help you get there quickly.

Stephen Kitt
  • 434,908