• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

pkg upgrade und "candidates" ?

Themenstarter #1
Hallo Allerseits,

was bedeutet bei pkg upgrade: "Checking for upgrades (12 candidates)" ?

kann ich die betroffene Pakete problemlos mit png upgrade -f aktualisieren?

Danke im Voraus für die Antwort.

Gruss,
Roki
 

holgerw

Well-Known Member
#2
Hallo Allerseits,

was bedeutet bei pkg upgrade: "Checking for upgrades (12 candidates)" ?

kann ich die betroffene Pakete problemlos mit png upgrade -f aktualisieren?

Danke im Voraus für die Antwort.

Gruss,
Roki
Hallo,

das -f ist hier überflüssig, das reinstalliert Dir sämtliche Pakete, auch solche, für die keine Aktualisierungen anliegen.
Ein
Code:
pkg upgrade
reicht hier.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#4
was bedeutet bei pkg upgrade: "Checking for upgrades (12 candidates)" ?
Die "Candidates" sind die Pakete, die eventuell aktualisiert werden müssen. Um das zu verstehen muss man erst einmal wissen, das pkg ein 'Alles oder Nichts'-Ansatz ist. Entweder es werden auch alle Abhängigkeiten der zu aktualisierenden Pakete mit aktualisiert oder gar nichts. Das ist ein einfacher, aber effizienter Weg um die Konsistenz des Gesamtsystems zu garantieren. Wenn zum Beispiel Paket A auf eine neue Version aktualisiert werden soll und diese neue Version gegen Version X von Paket B gebaut wurde, muss sichergestellt sein, dass lokal Paket B in dieser Version X installiert ist. Tatsächlich erstreckt sich das nicht nur über Versionen, stattdessen auch über Optionen und einige andere Attribute. Wenn das lokale Paket B mit anderen Optionen gebaut wurde als das Paket B, gegen welches das Paket A erstellt wurde, muss B lokal erstetzt werden.

pkg geht dabei relativ einfach vor. Bei 'pkg upgrade' schaut es erst einmal nach, welche Pakete lokal kleinere Versionen als die Pakete im Repository haben. Anschließend ermittelt es die direkten und indirekten Abhängigkeiten dieser Pakete, erstellt also einen Abhängigkeitsgraphen. Alle Pakete in diesem Abhängigkeitsgraphen sind die "Candidates". Danach geht er jedes einzelne Paket in dem Graphen durch, markiert es jeweils als gleich oder abweichend zum Repository. Danach wird der Graph in einen SAT-Solver [1] eingegeben, der ermittelt, welche Pakete lokal installiert, deinstalliert, aktualisiert oder ersetzt werden müssen, um auf einen konsistenten Zustand zu kommen.

Die meisten Probleme, die Nutzer mit pkg haben, ergeben sich daraus, dass sie dem Mechanismus ins Handwerk pfuschen oder ein Port Maintainer Mist gebaut hat. Der Klassiker ist ein Paket mit 'pkg lock' zu sperren, es damit sozusagen unaktualisierbar zu machen. pkg nimmt das Paket damit immer als übereinstimmend mit dem Repository an, ignoriert es bei allen Überlegungen. In der Realität ist es aber sehr wahrscheinlich nicht mit dem Paket im Reposity gleich, das Gesamtsystem wird damit inkonsistent. Problematisch ist auch, wenn neuere Versionen nicht als solche zu erkennen sind. Das ist zum Beispiel der Fall, wenn mail/dovecot1 durch mail/dovecot2 ersetzt wird. Da es auch Sicht von pkg ein neues Paket ist, muss ihm mitgeteilt werden, dass er mail/dovecot2 als eine neue Version mail/dovecot1 betrachten soll. Fehlt der entsprechende Datenbankeintrag, gehen Dinge schief.

1: https://en.wikipedia.org/wiki/Boolean_satisfiability_problem
 

mapet

Active OpenBSD User
#5
Ein Klassiker hier ist PHP, wenn die pecl Pakete nicht aktualisiert werden, aber php upgedatet wird. Hin und wieder braucht es dabei das -f als gut gemeinten Rat ;)