Why?

To install its runtime dependencies (libA, libB, …), which required version may not be available as a package in your Linux distribution.

Thus you have to deal with Github repositories clones, custom prefixes (~/dev/libA, ~/dev/libB) through the build/install process, and eventually LD_LIBRARY_PATH adjustments once you start your software, to ensure the correct runtime version of a library is used.

I bet installing everything to /usr, in a dedicated system, would make the whole process easier, isn’t it?

Docker is a low-footprint (compared to full VMs) solution to this problem. Everything (dependencies, work directory, compilations) will be restricted to a Docker container, and you can even run graphical applications.

For illustration purposes, I’m going to show you how to build and start the latest version of Fontforge, which is a graphical font editor.

I will use Archlinux for the host and Debian for the Docker container.

Everything is split across several lines and &&‘ed, to reduce layers and for the sack of producing meaningful diffs for further Dockerfile updates. sudo is just here if you want to play in the container as root later.

Build the Docker image

# docker build --tag fontforge

Run the container

To export the display system outside the container, we share the X11 host socket and $DISPLAY variable with the container.

Note: Sharing the X11 socket with the container is a comfort solution, not a secure one, because the container can read all your inputs (mouse, keyboard)