Les dépendances automagiques, ce qu'elles sont et comment les corriger

1.  Introduction

Qu'est-ce que les dépendances automagiques ?

Les fameuses dépendances automagiques sont des dépendances légères d'un logiciel qui ne sont reconnues qu'au moment de la compilation ou de l'exécution et qui influent sur le fonctionnement du logiciel. Le nom automagique est un jeu de mot en référence aux GNU autotools qui produisent le plus souvent des dépendances automagiques.

Les logiciels ont en général deux catégories de dépendances : les dépendances indispensables et les dépendances optionnelles. La première catégorie de dépendance est requise pour l'utilisation du logiciel (cela peut être une bibliothèque ou une application) et elles ne peuvent manquer à l'appel lors de la compilation ou l'exécution du logiciel (selon leur type :: dépendances de compilation ou d'exécution). Les dépendances optionnelles sont celles qui peuvent être désactivées, en général lors de la compilation (mais parfois aussi lors de l'exécution).

Il revient souvent à l'utilisateur (ou à celui qui compile le logiciel) d'activer ou désactiver les dépendances optionnelles. L'exemple classique de ce cas sont les options --enable-foo ou --with-bar du script ./configure (ces paramètres sont utilisés pour activer des dépendances qui sont désactivées par défaut, mais il y a également des cas pour lesquelles les dépendances sont activées par défaut et il faut donc utiliser --disable-foo ou --without-bar).

Cependant, avec des systèmes de compilation qui essaient de comprendre ce qui est présent sur le système qui sert à la compilation, il arrive que des dépendances deviennent automagiques. Cela signifie que le système de compilation ne demande pas à l'utilisateur s'il souhaite activer une option et donc ajouter une dépendance, mais que la dépendance est activée si elle est détectée. Ce comportement est mauvais.

Pourquoi les dépendances automagiques sont mauvaises

Dans le cas de distributions basées sur des binaires, comme celles basées sur RPM ou DEB, les dépendances automagiques ne changent rien : si l'utilisateur a quelque chose d'installé et qu'il compile à la main, c'est souvent qu'il veut activer l'option et, s'il s'agit du mainteneur, il n'aura qu'à ajouter une dépendance sur les paquets requis pour exécuter les binaires qu'il a créés.

Cela est différent pour les distributions basées sur les sources comme Gentoo Linux (et dérivés). Comme les distributions basées sur les sources ne séparent pas les paquets pour l'utilisateur des paquets de développement, les systèmes de construction peuvent trouver plus que ce que l'utilisateur voudrait et vont essayer de se lier avec tout ce qu'ils connaissent. C'est la principale cause de cassure des liaisons après un depclean (N.d.T. : nettoyage des dépendances non utilisées).

Pour simplifier, lorsqu'une dépendance automagique n'est pas indiquée comme indispensable dans un ebuild, mais qu'au lieu de cela il existe un mécanisme qui ajoute ou supprime la dépendance d'un paquet donné, si le paquet est présent dans le système compilant le logiciel avec des dépendances automagiques et est ensuite supprimé, le logiciel cessera de fonctionner, nécessitant alors une exécution de revdep-rebuild pour corriger la liaison. Il est également possible qu'un utilisateur souhaite réellement désactiver une dépendance parce qu'il sait qu'elle n'est pas stable ou parce qu'il crée un paquet binaire pour une autre machine sur laquelle la dépendance n'est peut-être pas installée (ou ne fonctionne même peut-être pas du tout).

Lorsqu'un paquet a des dépendances automagiques, il n'y a que deux solutions : la première est de déclarer la dépendance comme étant indispensable, sans considérer les choix faits par l'utilisateur dans la variable USE, mais cela peut signifier que le support de certaines fonctionnalités que certains utilisateurs ne souhaitent pas activer sera toujours présent et les dépendances seront toujours installées ; l'autre solution est de corriger le système de compilation pour qu'il soit capable de désactiver la dépendance lors de la compilation même si elle est présente sur le système.

La plupart du temps, les développeurs upstream (N.d.T. : les développeurs du logiciel) ne pensent pas vraiment à ajouter la possibilité de désactiver les dépendances automagiques puisqu'ils ne le ressentent pas comme un véritable problème : ils les ont toutes d'installées, ou au moins celles dont ils ont besoin, et ils compilent en général avec toutes les options d'activées. Heureusement, la plupart des développeurs upstream acceptent d'ajouter des options pour désactiver ces dépendances si des correctifs sont fournis (parfois également sans correctif, mais bien évidemment la demande sera mieux reçue si des correctifs sont déjà prêts). Ce n'est toutefois pas toujours le cas. Par exemple, les développeurs de Wine ne veulent pas ajouter la possibilité d'activer ou de désactiver des fonctionnalités lors de l'appel à ./configure car ils désirent que leur logiciel utilise toujours le plus d'options possible.

2.  Corriger les dépendances automagiques

Autotools

La majorité des dépendances automagiques, comme leur nom l'indique, sont dues à un (mauvais) usage des GNU autotools (autoconf pour être exact). Il y a deux cas principaux dans lesquels des dépendances automagiques apparaissent : le premier est le cas des « développeurs paresseux », dans lequel les dépendances n'ont pas du tout de paramètre pour ./configure et sont seulement vérifiées à l'aide de AC_CHECK_LIB ou la macro PKG_CHECK_MODULE de pkg-config, qui permettent l'exécution de code spécifique lorsqu'une bibliothèque ou un paquet sont présents ou non ; l'autre cas est celui du « paramètre malicieux » dans lequel les paramètres --disable-foo ou --without-bar sont acceptés par ./configure mais ne sont pas correctement interprétés.

Le premier cas est facile à corriger, il n'y a qu'à ajouter un appel à AC_ARG_WITH (ou AC_ARG_ENABLE) et ensuite vérifier la valeur de la variable correspondante avant de faire le test. Il est utile de savoir que le premier paramètre passé à cette macro crée une variable qui est chargée par autoconf sans avoir à ajouter les autres paramètres qui déterminent l'action à effectuer lorsque le paramètre est présent et lorsqu'il ne l'est pas. Cette variable est appelée $enable_foo ou $with_bar en fonction de la macro utilisée.

AC_ARG_WITH([foo], AS_HELP_STRING([--without-foo], [Build without foo library (default: test)]))

if test "x$with_foo" != "xno"; then
  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
fi

AC_ARG_WITH([foo], AS_HELP_STRING([--with-foo], [Build with foo library (default: disabled)]))

if test "x$with_foo" == "xyes"; then
  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
fi

Lorsque le paramètre est présent mais n'est pas honoré, corriger le problème de dépendance peut aussi bien être simple que complexe. Il peut s'agir d'un test qui n'est pas correctement écrit, et dans ce cas il faut le modifier en quelque chose qui ressemble aux tests présentés précédemment, ou il peut s'agir d'un mélange complet des appels aux macros AC_ARG_WITH. Dans ces cas, il vaut mieux vérifier le code avec précaution et contacter les développeurs upstream s'il s'agit d'une erreur complexe.

Il y a en réalité une autre méthode, sans correction, pour contourner le problème des dépendances automagiques générées par AC_CHECK_LIB et c'est en jouant avec les valeurs mises en cache par autoconf. Cette méthode est en fait dépréciée parce qu'elle ne règle pas la cause du problème et peut en créer d'autres si les développeurs upstream modifient légèrement les tests en utilisant un autre nom pour la variable mise en cache. De plus, de cette façon, les correctifs ne peuvent être envoyés aux développeurs upstream pour être intégrés dans les prochaines versions.

CMake

Les dépendances automagiques peuvent poser problème avec les systèmes basés sur CMake où PKG_CHECK_MODULES est appelé sans le paramètre REQUIRED de façon inconditionnelle. Corriger cela est assez facile puisqu'il s'agit simplement d'introduire une option afin de compiler le système et d'exécuter PKG_CHECK_MODULES, en fonction de sa valeur.

OPTION(ENABLE_FOO "Enable foo library" ON)
...
IF (ENABLE_FOO)
  PKG_CHECK_MODULES (FOO foo>=0.1)
ENDIF (ENABLE_FOO)
...
IF (ENABLE_FOO)
  IF (FOO_FOUND)
  ...
  ELSE (FOO_FOUND)
  ...
  ENDIF (FOO_FOUND)
ENDIF (ENABLE_FOO)

Les autres systèmes de compilation

Les dépendances automagiques peuvent également être créées par des systèmes de construction utilisés par certains logiciels. Malheureusement, du fait de leur personnalisation, ces systèmes de construction sont en général difficiles à optimiser et il n'est pas possible de définir une méthode d'approche générale pour les corriger.

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.