"pkg_add -ui" vs. "make update"

[nihonto]

Hiho!

Folgende Frage: Was ist sinnvoller: Updates über "pkg_add -ui" oder über die Ports (mit /usr/ports/infrastructure/build/out-of-date)? Warum ich frage? Beide Update-Möglichkeiten wissen offenbar nichts voneinander.

Bsp.: Vorhin habe ich ein "pkg_add -ui" laufen lassen, wobei png-1.2.14p0 auf png-1.2.14p1upgedatet worden ist. Nachdem ich nun aber auch die Ports über cvsup neu gezogen habe (um Opera 9.21 zu bekommen) und das out-of-date script habe laufen lassen, wird mir immer noch angezeigt, dass png-1.2.14p0 zu erneuern sei auf Version png-1.2.14p1.

Finde das etwas verwirrend und frage mich, ob sich das nicht umgehen bzw. abstellen lässt.

 

[oenone]

wird mir immer noch angezeigt, dass png-1.2.14p0 zu erneuern sei auf Version png-1.2.14p1.

dann ist beim vorherigen update mittels pkg_add etwas schief gelaufen.

Generell solltest du die ports gar nicht benutzen (müssen). Packages sind immer die beste Methode.

"pkg_add -u" prüft lediglich, ob im PKG_PATH neuere (bzw. andere) Versionen der installierten Packages vorhanden sind.

"out-of-date" prüft dies mittels des aktuellen ports-trees. Da die Packages auf den FTP-Servern nicht unbedingt auf dem allerneuesten Stand sein könnten, ist es möglich, dass "out-of-date" mehr neuere Versionen findet als "pkg_add -u". Es geht jedoch immer von den installierten Packages aus und vergleicht diese mit den neu erstellten ports-Signaturen.

Daher: Überprüf, ob png wirklich auf der neuesten Version ist und wenn nicht, überprüf, warum pkg_add gescheitert ist.

auf bald
oenone

 

[nihonto]

Hi und vielen Dank für die Antwort !

Habe mich aber wohl ein bisschen zu umständlich ausgedrückt: pkg_add hat prima funktioniert (png wurde von Version 1.2.14p0 auf 1.2.14p1 upgedatet), aber davon bekommt offenbar dieses "out-of-date" script nichts mit. Kann es sein, dass es in einem anderen Verzeichnis o.ä. nachsieht und die Versionsnummern der installierten Pakete mit denen auf dem Server vergleicht?

Wenn ich das script laufen lasse, kommt dieser output:

# cd /usr/ports/infrastructure/build/
# ./out-of-date
Collecting installed packages
Collecting port versions: complete
Collecting port signatures: complete
Outdated ports:

devel/pango # cairo-1.2.6 -> cairo-1.2.6p0
graphics/cairo # png-1.2.14p0 -> png-1.2.14p1
graphics/imlib # png-1.2.14p0 -> png-1.2.14p1
graphics/imlib2 # png-1.2.14p0 -> png-1.2.14p1
www/opera-flashplugin # opera-9.10 -> opera-9.21
x11/gtk+2,-main # png-1.2.14p0 -> png-1.2.14p1
x11/mplayer # png-1.2.14p0 -> png-1.2.14p1

Demgegenüber liefert ein "pkg_info" bezüglich der vermeintlich veralteten Pakete das hier:

cairo-1.2.6p0 vector graphics library
png-1.2.14p1 library for manipulating PNG images
opera-9.21 fast and customizable WWW browser

Also sieht es doch so aus, dass die Pakete aktuell sind, der Ports-Check mit out-of-date das aber nicht mitbekommt, oder?

Erinnert mich ein wenig an die Unterschiede zwischen apt-get und aptitude in Debian. Diese Paketverwaltungs-Frontends greifen bei den Abhängigkeiten auf unterschiedliche Datensätz zurück. Beim Umstieg von apt-get auf aptitude hatte ich dann ein bisschen was zu tun .

Auf die Ports würde ich auch gerne verzichten (bin kein Fan davon). Aber leider gibt es einfach zu viele Anwendungen, die ich gerne benutzen möchte, die aber nur in den Ports vorliegen: Java, Opera + das Flashplugin, die win32-codecs etc. pp.

Wenn das nicht wäre, würde ich ausschließlich mit "pkg_add -ui" arbeiten. Ist einfach, schnell und scheint mehr oder weniger fehlerfrei zu arbeiten .

 

[oenone]

graphics/imlib2 # png-1.2.14p0 -> png-1.2.14p1

das bedeutet nicht dass png zu alt ist, sondern, dass graphics/imlib2 zu alt ist und der Grund dafür ist, weil png sich von p0 zu p1 geändert hat.

"zu alt" bezieht sich hier darauf, dass es entweder eine neuere version gibt, oder dass sich eine der abhängigkeiten geändert hat und es neu kompiliert (bes. gelinkt) werden sollte. In deinem fall trifft genau das zu. png hat sich geändert und imlib2 ist davon abhängig bzw. damit gelinkt. lösung: imlib2 neu installieren (bzw. kompilieren).

auf blad
oenone

 

[nihonto]

Okay, das macht es klarer . Sollte ich denn dann die betroffenen Anwendungen aus den Ports kompilieren, oder sollte ich warten, bis die Pakete in der aktualisierten Form mittels pkg_add zu beziehen sind?

Eigentlich möchte ich nämlich so ein Mischmaschsystem vermeiden, bei dem irgendwann 50% der Anwendungen aus den Ports kommen und 50% über das Paketverwaltungssystem.

 

[kili]

Okay, das macht es klarer . Sollte ich denn dann die betroffenen Anwendungen aus den Ports kompilieren, oder sollte ich warten, bis die Pakete in der aktualisierten Form mittels pkg_add zu beziehen sind?

Die kleinen Mismatches in der Ausgabe von out-of-date kannst Du getrost ignorieren. Beim Erstellen der Packages werden halt die *exakten* Versionen der Dependencies mit in die Packinglist geschrieben (also z.B. png-1.2.14p0), das heisst aber nicht, dass so ein Paket nicht auch mit einer etwas neueren Dependency laeuft.

Eigentlich möchte ich nämlich so ein Mischmaschsystem vermeiden, bei dem irgendwann 50% der Anwendungen aus den Ports kommen und 50% über das Paketverwaltungssystem.

Brauchst Du auch nicht, ausser halt fuer diejenigen Ports, fuer die keine Packages zur Verfuegung gestellt werden koennen. Apropos: espie@ hat gerade neulich pkg_add(1) derart erweitert, dass es (optional) Abhaengigkeiten, die nicht im PKG_PATH gefunden werden, aus dem Portstree gebaut werden koennen. Ab OpenBSD 4.2 wird sich das Problem mit derartigen Ports also einigermassen entschaerfen. Hilft natuerlich nichts, wenn schon die Sourcen nicht frei sind, wie z.B. (noch) bei den JDKs.

 

[nihonto]

Apropos: espie@ hat gerade neulich pkg_add(1) derart erweitert, dass es (optional) Abhaengigkeiten, die nicht im PKG_PATH gefunden werden, aus dem Portstree gebaut werden koennen. Ab OpenBSD 4.2 wird sich das Problem mit derartigen Ports also einigermassen entschaerfen. Hilft natuerlich nichts, wenn schon die Sourcen nicht frei sind, wie z.B. (noch) bei den JDKs.

Goil - vielen Dank für den Hinweis

 

[Maxx]

espie@ hat gerade neulich pkg_add(1) derart erweitert, dass es (optional) Abhaengigkeiten, die nicht im PKG_PATH gefunden werden, aus dem Portstree gebaut werden koennen.

Nur als Abhaengigkeiten oder werden solche Pakete auch neugebaut, wenn ich einfach alle Pakete aktualisieren will? Ich meine, ob pkg_add dann z.B. Opera auch updaten koennte.

Maxx

 

[kili]

Nur als Abhaengigkeiten oder werden solche Pakete auch neugebaut, wenn ich einfach alle Pakete aktualisieren will? Ich meine, ob pkg_add dann z.B. Opera auch updaten koennte.

Ich hab's nicht ausprobiert, aber im Prinzip muesste es auch direkt fuer Updates funktionieren. Aber einfach mal abwarten, espie@ schraubt z.Z. ziemlich heftig an den pkg_tools herum, und das Feature ist ja noch nicht mal in der Manpage dokumentiert