Introduction

As opposed to the Windows world, there is a lot of open source software for Linux. As a result, there's a lot of code reuse, thus applications typically have a lot of dependencies. The number of dependencies can cause headaches for users when they try to install applications.

The existance of autopackage does not make the problem of dependencies magically disappear. So how do we handle dependencies in a way that makes life easier for users, but still not highly inefficient?

Recommendation

First you must make a distinction between types of dependencies:

A. System dependencies/popular dependencies.

  • Examples are: X11, GTK+, Qt 3, kdelibs, libxml, etc.
    • These libraries are all very widely deployed. Almost everybody have them so it's not very useful to try to depsolve/ship them.
    • In case of GTK and GNOME/KDE: you can't even reliably install them yourself! Every distribution has patched GNOME and KDE. For example, if you install stock GNOME on Fedora, you'll find that your menus are all screwed up.

B. Unpopular and/or unstable dependencies.

  • "Unpopular" means that these dependencies are not installed by default on many systems, not that they're bad quality/useless/etc.
  • Examples of unpopular libraries: gtkmm, libsigc++, gtkspell, Qt 4. Good libraries, but not many people have them by default. At the moment, KDE 4 isn't out yet, so it's unlikely anybody has Qt 4 by default.
  • Example of unstable library: WxWidgets?. Very unstable in terms of backwards compatibility. Plus, almost nobody has it installed by default. Those who do probably don't have it in the right ABI (the WxWidgets? ABI changes depending on whether it's compiled for GTK1 or GTK2, and whether unicode is enabled). Yes I know it sucks to make your binaries 3 MB larger. But the installation headaches suck even more.
  • See LibrariesToStaticallyLink for more.
  • You should dynamically link to dependancies in the category A, and specify them as required dependency for your program. Most users will have it so you can afford it.
  • Dependencies in the category B: you should either statically link to them, or ship the dependencies with your package by default.
    • If you choose for shipping the dependencies, then always install them to a private directory! Never, ever install shipped dependencies to the system's library folder, thus risking overwriting existing files! Windows DLL hell!
    • Alternatively, if your dependency is also available as an autopackage, then you can specify it as a required dependency. Autopackage supports auto-downloading of depdencies.
    • APBuild makes it very easy to statically link to libraries. See LibrariesToStaticallyLink for tips.

Mapping libraries to dependencies

Some developers don't know how to map a library (libgdk-2.0.so for example) to a dependency (GTK+). Here we'll maintain a list of mappings and recommendations for various dependencies. If you have a dependency not listed here, and don't know what to do with it, then please subscribe to the mailing list. We'll update this page if necessary.

Note that there may be multiple versions of a library. Newer versions typically have more functions. So it is important that you can specify the minimum required version of a certain library. It would suck if a user finds out that the package installed correctly, but the app can't run because of missing dependencies, or dependencies that are too old, right?

GTK/GNOME stack

  • libgtk-x11-2.0/libgdk-x11-2.0/libgdk_pixbuf-2.0 - in fact one big dependency (instead of 3): GTK+. Most people have GTK+. You should dynamically link to it.
    • GTK+ 2 has various versions: 2.0, 2.2, 2.4, 2.6, etc. If you don't know what the minimum version of GTK is that your app needs, then there's a way to find out.
      • Go to the GTK+ API reference page. For each function, the API reference will tell you in which version that function appeared first ("Since:"). If you don't see "Since:", then that means the function was available since 2.0.
      • Do you remember the old GTK file selector (the one with folders on the left pane, and files on the right pane, like the Motif one), GtkFileSelection? The new file selector (GtkFileChooserm which looks like MacOS X's) appeared first in GTK 2.4. So if your app uses GtkFileChooser, then your app depends on at least GTK 2.4.
      • Too much trouble? Try to compile your app with older GTK headers. See the tarball's README about how to use it. Here's an example: {{{export APBUILD_INCLUDE="/usr/local/gtk-headers/2.2"

./configure && make clean && make}}}

If your app compiles & runs without errors, then your app depends on GTK 2.2 or earlier. Change the "2.2" part in the above code to find out the minimum required version of GTK.

  • libgobject-2.0/libglib-2.0/libgmodule-2.0/libgthread-2.0 - also one single dependency: glib. Most people have it, so dynamically link to it. GTK+ depends on Glib, so if your app depends on GTK+ then you only needs to check for GTK+, not Glib!
  • libgnomevfs-2 - GNOME-VFS, part of GNOME since 2.0. You should dynamically link to it.
  • libgnome-2/libgnomeui-2 - Part of GNOME since 2.0. Dynamically link to it.
  • libgnome-desktop-2/libgnome-menu - Part of the GNOME Desktop Platform since 2.10. Libraries in the Desktop Platform (as opposed to the Developer Platform) are unstable and can break compatibility. Dynamic link to them, but be careful and regularly check whether your app still works on the most recent version of GNOME!

System libraries

  • libpthread.so.0 - part of glibc. Everybody has it. No need to check for it.
  • libc.so.6 - glibc. Everybody has it. No need to check for it.
  • See also LibrariesToStaticallyLink for dependencies that you should statically link to.

Packages that do not need to be detected

  • libfontconfig.so.0 - Both Qt and GTK require on fontconfig, no need to check for it in your package.

Caveats

  • If your app depends on GTK, then always compile with older GTK headers! Otherwise, your binary may end up with bogus dependencies on newer versions of GTK. The old GTK headers tarball's README explains the problem in detail.
  • Ditto for glibc: you may end up with bogus dependencies on newer glibc symbols. Apbuild automatically fixes this so use apbuild whenever possible!