Telkens u in aptitudekiest om een pakket te installeren of op te waarderen, doet aptitude onmiddellijk een poging om alle niet-voldane vereisten ervan op te lossen. Voor elke niet-voldane vereiste (dit kan ofwel een “Depends” (vereiste), een “ Recommends” (aanbeveling) of een “Conflicts” (conflict) zijn), voert het de volgende stappen uit:
Als de vereiste een aanbeveling is, tracht aptitude te gissen of het een “nieuwe” aanbeveling betreft of een “eerder voldane” aanbeveling. aptitude beschouwt een aanbeveling als “nieuw” als het pakket dat de aanbeveling doet momenteel niet geïnstalleerd is of als zijn geïnstalleerde versie geen pakket met dezelfde naam aanbeveelt. Daarentegen werd “eerder voldaan” aan een aanbeveling als het pakket dat de aanbeveling doet, geïnstalleerd is, de momenteel geïnstalleerde versie een pakket met dezelfde naam aanbeveelt en er momenteel aan die aanbeveling voldaan wordt.
Veronderstel bijvoorbeeld dat versie 1.0
van
prog
versie 4.0
van
libcool1
aanbeveelt, maar dat versie
2.0
van prog
versie
5.0
van libcool1
aanbeveelt evenals
apache
. Als u ervoor kiest om prog
van
versie 1.0
naar versie2.0
op te
waarderen, zal het aanbevelen van apache
als
“nieuw” beschouwd worden, omdat versie 1.0
van prog
apache
niet
aanbeval. Daarentegen is het aanbevelen van libcool1
niet “nieuw”, omdat versie
1.0
van prog
libcool1
reeds aanbeval, ook al beval het een andere
versie aan. Niettemin zal die aanbeveling als “eerder voldaan”
beschouwd worden, als libcool1
geïnstalleerd is.
Indien de configuratieoptie APT::Install-Recommends
ingesteld staat op true
, zal aptitude steeds proberen
te voldoen aan “nieuwe” en “eerder voldane”
aanbevelingen. Alle andere zullen door de onmiddellijke oplosser genegeerd
worden. Indien die optie op false
ingesteld staat, zal de
onmiddellijke vereistenoplosser alle aanbevelingen
negeren.
Indien de vereiste slaat op meerdere pakketten gecombineerd met een logische
OR, wordt elk van de alternatieven in de opgegeven volgorde
onderzocht. Indien een pakket bijvoorbeeld “exim |
mail-transport-agent
” vereist, zal aptitude eerst
exim
afhandelen en dan
mail-transport-agent
.
Tracht dit voor elk alternatief op te lossen. Indien de afhankelijkheid een conflict betreft, verwijder dan het huidige alternatief als het geïnstalleerd is (en verwijder bij een versieloos conflict ook elk pakket dat voorziet in het doel dat het conflict uitlokte). Installeer anders de kandidaatversie van het huidige alternatief als het aan de vereiste tegemoet komt. Is dit niet het geval of indien er geen kandidaatversie is (bijvoorbeeld omdat het huidige alternatief een virtueel pakket is) en het een versieloze afhankelijkheid betreft, probeer dan over te gaan tot de installatie van het pakket met de hoogste prioriteit[12] waarvan de kandidaatversie voorziet in het doel van het huidige alternatief.
Laten we bijvoorbeeld stellen dat we het volgende proberen op te lossen:
“Depends: exim |
mail-transport-agent
”. aptitude zal dan eerst proberen
het pakket exim
te installeren. Als
exim
niet beschikbaar is, zal aptitude vervolgens
proberen het pakket met de hoogste prioriteit te installeren waarvan de
kandidaatversie voorziet in exim
. Als er geen dergelijk
pakket is, zal aptitude het pakket met de hoogste prioriteit installeren
waarvan de kandidaatversie het virtueel pakket
mail-transport-agent
levert. Laten we daarentegen nu
veronderstellen dat het gaat om de vereiste “Depends: exim
(>= 2.0.0) | mail-transport-agent
”, maar dat enkel versie
1.0
van exim
beschikbaar is. In dat
geval zal aptitude exim
niet installeren (omdat de
versie niet beantwoordt) en het zal ook niet proberen pakketten te
installeren die voorzien in exim
(omdat virtuele
pakketten niet tegemoet kunnen komen aan een vereiste met een
versierestrictie). En dus zal aptitude terugvallen op het installeren van
het pakket met de hoogste prioriteit waarvan de kandidaatversie voorziet in
mail-transport-agent
.
Indien bij de vorige stap een pakket geïnstalleerd werd, los dan met dit algoritme zijn vereisten op en stop vervolgens.
Hoewel deze techniek heel vaak alle onvoldane vereisten van pakketten oplost, kan ze toch in een aantal gewone omstandigheden tekortschieten.
Conflicten worden opgelost door het doelpakket dat het conflict uitlokte,te verwijderen. Maar in dat geval krijgen pakketten die van dat pakket afhankelijk waren, te maken met onvoldane vereisten. En de onmiddellijke oplosser zal geen poging doen om die te repareren.
Soms kan niet aan een vereiste voldaan worden ten gevolge van
versierestricties en ten gevolge van de beperking dat enkel kandidaatversies
in overweging genomen worden. Veronderstel bijvoorbeeld dat van
fileutils
de versies 1.0
en
2.0
beschikbaar zijn, dat de kandidaatversie versie
1.0
is en dat het pakket octopus
de
volgende vereiste stelt: “Depends: fileutils (>=
2.0)
”. De onmiddellijke oplosser is in een dergelijk geval
niet in staat de vereiste op te lossen: hij zal nooit versie
2.0
van het pakket in overweging nemen, aangezien dat
niet de kandidaatversie is.
De interactieve vereistenoplosser kan deze situaties en nog andere wel oplossen. Indien er onvoldane vereisten achterblijven of indien de onmiddellijke vereistenoplossing uitgeschakeld is, zal de interactieve oplosser automatisch beginnen zoeken naar een oplossing. Het volgende onderdeel beschrijft hoe men de interactieve vereistenoplosser moet gebruiken.