| Résolution immédiate des dépendances | ||
|---|---|---|
 | Résoudre les dépendances de paquets |  |
| Résolution immédiate des dépendances | ||
|---|---|---|
| | Résoudre les dépendances de paquets | |
Dès que vous choisissez d'installer ou de mettre à jour un paquet avec aptitude, aptitude essaie immédiatement de résoudre toutes les dépendances qui ne sont pas satisfaites. Pour chaque dépendance non satisfaite (qu'elle soit du type « Depends », « Recommends » ou « Conflicts »), il effectue les étapes suivantes :
Si la dépendance est une recommandation (« Recommends »), aptitude essaie de deviner s'il s'agit d'une « nouvelle » recommandation, ou si elle était déjà « satisfaite précédemment ». aptitude considère une recommandation comme étant « nouvelle » si le paquet qui la déclare n'est pas actuellement installé, ou si la version installée ne recommande pas de paquet du même nom. Au contraire, une recommandation est considérée comme étant « satisfaite précédemment » si le paquet déclarant cette recommandation est installé, que la version actuelle recommande un paquet du même nom, et que cette recommandation est actuellement satisfaite.
Par exemple, supposons que la version 1.0 de
prog recommande la version 4.0 de
libcool1, mais que la version 2.0 de
prog recommande la version 5.0 de
libcool1, ainsi que le paquet
apache. Si vous choisissez de mettre à jour
prog de la version 1.0 vers la version
2.0, la recommandation d'apache sera
considérée comme « nouvelle » car la version
1.0 de prog ne recommandait pas
apache. D'autre part, la recommandation de
libcool1 n'est pas « nouvelle », puisque la
version 1.0 de prog recommandait
libcool1, même s'il s'agissait d'une version
différente. Si libcool1 est installée, cette
recommandation sera considérée comme étant « satisfaite
précédemment ».
Si l'option de configuration APT::Install-Recommends
est vraie (« true »), aptitude essaiera
toujours de satisfaire les « nouvelles » recommandations, ainsi
que celles qui étaient « satisfaites précédemment ». Toutes les
autres seront ignorées par la résolution immédiate. Si cette option est
fausse (« false »), la résolution immédiate
ignorera toutes les recommandations.
Si la dépendance porte sur plusieurs paquets, combinés avec un OU, examiner
chaque alternative dans l'ordre donné. Par exemple, si un paquet dépend de
« exim | mail-transport-agent », aptitude
traitera d'abord exim, puis
mail-transport-agent.
Pour chaque alternative, essayer de résoudre la dépendance. Si la dépendance est un conflit, supprimer l'alternative examinée si elle est installée (et pour un conflit sans indication de version, supprimer aussi tout paquet fournissant la cible du conflit). Sinon, installer la version candidate de l'alternative examinée si elle satisfait la dépendance. Si elle ne la satisfait pas, ou s'il n'y a pas de version candidate (par exemple, si l'alternative examinée est un paquet virtuel), et si la dépendance n'indique pas de version, essayer d'installer le paquet avec la plus haute priorité[12] dont la version candidate fournit la cible de l'alternative examinée.
Par exemple, si la dépendance à résoudre est « Depends: exim |
mail-transport-agent », aptitude essaiera d'abord
d'installer le paquet exim. Si exim
n'est pas disponible, aptitude essaiera alors d'installer le paquet avec
la plus haute priorité dont la version candidate fournit
exim. S'il n'y a pas de tel paquet, aptitude installera
le paquet avec la plus haute priorité dont la version candidate fournit le
paquet virtuel mail-transport-agent. Si maintenant, la
dépendance examinée est « Depends: exim (>= 2.0.0) |
mail-transport-agent », et que seule la version
1.0 d'exim est disponible, aptitude
dans ce cas n'installera pas exim (car la version ne
correspond pas), et n'essaiera pas non plus d'installer un paquet
fournissant exim (car les paquets virtuels ne peuvent pas
correspondre à une dépendance avec une restriction de version). Donc,
aptitude installera le paquet avec la plus haute priorité dont la version
candidate fournit mail-transport-agent.
Si un paquet a été installé à l'étape précédente, résoudre ses dépendances avec cet algorithme, puis arrêter.
Bien que cette technique résolve très souvent la totalité des dépendances entre paquets en jeu, elle peut échouer dans un certain nombre de cas communs.
Des conflits peuvent être résolus en supprimant le paquet qui est la cible du conflit. Mais les autres paquets qui dépendent de ce paquet ont maintenant des dépendances non satisfaites. La résolution immédiate n'essaie pas de les satisfaire.
Une dépendance peut ne pas être satisfaite à cause d'une restriction de
version, ou de la limitation que seules les versions candidates sont
envisagées. Par exemple, supposons que les versions 1.0
et 2.0 de fileutils sont disponibles,
que la version candidate est la 1.0 et que le paquet
octopus déclare une dépendance « Depends:
fileutils (>= 2.0) ». La résolution immédiate est incapable
de résoudre cette dépendance : elle ne considérera jamais la version
2.0 du paquet, puisqu'elle n'est pas candidate.
Le solveur interactif de dépendances peut résoudre ces situations, et bien d'autres. Lorsqu'il y a des dépendances cassées restantes, ou que la résolution immédiate est désactivée, le solveur interactif commence automatiquement à chercher une solution. La section suivante décrit comment utiliser le solveur interactif.
| |  | |
| Résolution des dépendances dans aptitude |  | Résolution interactive des dépendances |