De kost van een oplossing die door de interactieve
vereistenoplosser geproduceerd wordt, is een waarde die door aptitude
gebruikt wordt om te bepalen hoe “slecht” die oplossing
is. Oplossingen die “beter” zijn, worden steeds weergegeven
voor oplossingen die “slechter” zijn. De kost van oplossingen
wordt gedefinieerd in de configuratieoptie Aptitude::ProblemResolver::SolutionCost
.
Enkele kenmerkende kosten worden getoond in Voorbeeld 2.1, “Kostenvoorbeelden van de oplosser”.
Voorbeeld 2.1. Kostenvoorbeelden van de oplosser
De standaardkost, waarbij oplossingen geordend worden volgens hun veiligheidskost en vervolgens volgens hun pinprioriteit voor apt:
safety, priority
Verwijder zo weinig mogelijk pakketten en annuleer vervolgens zo weinig mogelijk acties:
removals, canceled-actions
Sorteer oplossingen volgens het aantal pakketten dat zij verwijderen plus tweemaal het aantal acties dat zij annuleren.
removals + 2 * canceled-actions
Zoals u in de bovenstaande voorbeelden kunt zien, is een kost niet
noodzakelijk een enkel getal. In feite bestaat een kost uit een of meer
kostencomponenten, waarbij elk van hen een getal is
dat verbonden is met de oplossing. Bij het rangschikken van oplossingen,
onderzoekt de oplosser kostencomponenten volgens volgorde en gaat enkel
voort naareen volgende component als de vorige gelijk zijn. Bijvoorbeeld
zullen voor de kost “removals,
canceled-actions
” oplossingen met minder verwijderingen
steeds voorafgaan aan oplossingen met meer verwijderingen, ongeacht het
aantal geannuleerde acties dat ze met zich meebrengen. Oplossingen met een
gelijk aantal verwijderingen worden van hun kant zodanig geordend dat de
oplossing met het minste aantal geannuleerde acties op de eerste plaats
komt.
Kostencomponenten komen voor in twee verschijningsvormen: basale kostencomponenten en samengestelde kostencomponenten.
Basale componenten benoemen gewoon een kenmerk van de oplossing,
zoals“upgrades
” (opwaarderingen) of
“removals
” (verwijderingen). Een lijst met
ingebouwde basiscomponenten van aptitude kunt u vinden in Tabel 2.1, “Basale kostencomponenten”. U kunt ook uw eigen kostencomponenten
maken met de hints add-to-cost-component
en
raise-cost-component
. Zie voor de details de paragraaf met de naam “Hints voor de oplosser configureren”.
Elke basiscomponent is ofwel een teller of een niveau. Tellers tellen hoeveel acties van een oplossing aan een bepaalde voorwaarde voldoen (zoals pakketten verwijderen of nieuwe pakketten installeren), terwijl niveaus een getal koppelen aan iedere actie en berekenen wat het hoogste getal is dat aan een actie uit de oplossing gekoppeld is.
Tabel 2.1. Basale kostencomponenten
Naam | Type | Omschrijving |
---|---|---|
broken-holds | Teller |
Telt het aantal handhavingen dat de oplossing verbreekt als de oplosser de
toelating heeft om dat te doen (Aptitude::ProblemResolver::Allow-Break-Holds ).
|
canceled-actions | Teller | Telt het aantal aanhangige acties dat door de oplossing geannuleerd wordt (zodat pakketten op hun huidige versie behouden blijven). |
installs | Teller | Telt het aantal pakketten dat door de oplossing geïnstalleerd wordt. |
non-default-versions | Teller | Telt het aantal versies dat de oplossing installeert of opwaardeert vanuit niet-standaard pakketbronnen. |
priority | Niveau | Een waarde die toeneemt naarmate de pinprioriteit voor apt van een versie afneemt. Meer bepaald wordt dit berekend door de pinprioriteit negatief te maken (als bijvoorbeeld de pinprioriteit 500 is, zal deze component de waarde -500 krijgen). |
removals | Teller | Telt het aantal pakketten dat door de oplossing verwijderd wordt. |
removals-of-manual | Teller | Telt het aantal handmatig geïnstalleerde pakketten dat door de oplossing verwijderd wordt. |
safety | Niveau | Een algemene heuristische waarde die toeneemt naarmate acties minder “veilig” worden. Zie voor details de paragraaf met de naam “Veiligheidskosten”. |
upgrades | Teller | Telt het aantal pakketten dat door de oplossing opgewaardeerd wordt. |
Samengestelde componenten worden opgebouwd door de waarden van basale
componenten te combineren. Bijvoorbeeld, removals +
canceled-actions
telt de componenten removal
en
canceled-actions
bij elkaar op en het resultaat is een
component die het aantal verwijderingen en geannuleerde
acties telt. Samengestelde componenten combineren tellers door ze bij elkaar
op te tellen en niveaus door hun maximale waarde te nemen, zoals
gedemonstreerd in Afbeelding 2.11, “Syntaxis van samengestelde kostencomponenten”.
![]() | Opmerking |
---|---|
Twee niveaus samenvoegen is foutief, en dat geldt ook voor het gebruiken van
de maximumwaarde van twee tellers en voor het op een af andere manier
combineren van niveaus en tellers. Bijvoorbeeld zullen de kosten
|
Afbeelding 2.11. Syntaxis van samengestelde kostencomponenten
Twee of meer basale kosten optellen:
[schaalfactor1
]*kost1
+ [schaalfactor2
]*kost2
+ ...
De maximumwaarde van twee of meer basale kosten gebruiken:
max([schaalfactor1
]*kost1
, [schaalfactor2
]*kost2
, ...)
Merk op dat elke individuele basale component vermenigvuldigd kan worden met
een schaalfactor vooraleer hij gecombineerd wordt met andere
componenten. Dit kan gebruikt worden om de afwegingen die de oplosser tussen
kosten maakt, te sturen. Een kost van 2*removals +
3*upgrades
zegt dat drie verwijderingen exact even
“slecht” zijn als twee opwaarderingen. Oplossingen met vier
verwijderingen en één opwaardering zullen gezien worden als gelijkwaardig
aan oplossingen met één verwijdering en drie opwaarderingen, aangezien beide
een kost van elf hebben.
De kostencomponent veiligheid
is een heuristische
schatting van hoe “veilig” of “onveilig” een
oplossing is. Veiligheidskosten kunnen gezien worden als een manier van
onderverdelen van oplossingen in verschillende genummerde
“niveaus”, waarbij “minder veilige” niveaus een
hoger nummer opgeplakt krijgen. Afbeelding 2.12, “Niveaus van veiligheidskosten”
toont hoe dit werkt met de standaardinstellingen van aptitude.
![]() | Tip |
---|---|
Niveaus van veiligheidskosten zijn enkel een manier om de volgorde te sturen waarin vereistenoplossingen geproduceerd worden. Zie de paragraaf met de naam “Kosten van de interactieve vereistenoplosser” voor een volledige beschrijving van hoe u de volgorde waarin aptitude oplossingen rangschikt, kunt wijzigen. |
Standaard start aptitude de oplosser op met een “redelijk” aantal niveaus van veiligheidskosten. Die zijn:
Tabel 2.2. Standaard niveaus van veiligheidskosten
Kostenniveau | Omschrijving | Configuratieoptie |
---|---|---|
10.000 | Oplossingen die enkel “veilige” acties inhouden (het installeren van een pakket op zijn standaardversie of het behouden van een pakket op zijn huidige versie) en het verwijderen van pakketten. | Aptitude::ProblemResolver::Safe-Level ,
Aptitude::ProblemResolver::Remove-Level |
10.000 |
The solution that cancels all the user's actions. It used to be higher than
Aptitude::ProblemResolver::Remove-Level ,
but removing packages was ranked higher than keeping the same packages, even
if the package was to be upgraded.
| Aptitude::ProblemResolver::Keep-All-Level |
40.000 | Oplossingen die door de gebruiker ingestelde handhavingen verbreken of verboden versies installeren. | Aptitude::ProblemResolver::Break-Hold-Level |
50.000 |
Oplossingen die pakketten installeren op een versie die niet de
standaardversie is (zoals bijvoorbeeld die uit
“experimental ”).
| Aptitude::ProblemResolver::Non-Default-Level |
60.000 | Oplossingen die essentiële pakketten verwijderen. | Aptitude::ProblemResolver::Remove-Essential-Level |
Indien een oplossing thuis hoort onder meerdere niveaus van veiligheidskosten, zal het onder het hoogste geplaatst worden, dat is datgene dat zich het laatst aandient. Een oplossing die bijvoorbeeld een pakket opwaardeert naar zijn standaardversie en een handhaving van een ander pakket verbreekt, zal op niveau 40.000 geplaatst worden. U kunt de niveaus van individuele versies aanpassen met behulp van hints voor de oplosser. Zie voor details de paragraaf met de naam “Hints voor de oplosser configureren”. De standaardniveaus worden geïllustreerd in Afbeelding 2.12, “Niveaus van veiligheidskosten”.
[13] Deze limiet werd ingesteld omdat nog meer complexe kostenstructuren het moeilijk zouden maken om de oplosser te optimaliseren. Uit toekomstige versies van het programma zouden sommige restricties verwijderd kunnen worden als ze niet noodzakelijk blijken te zijn.