Das Portmanagement in FreeBSD...

[TayTay]

Hallo zusammen

Irgendwie kommt mir das mit dem Portmanagement unlogisch vor...
Angeblich sollen Basisystem und Ports getrennt sein.
Für den Update des Basissystems soll angeblich ein freebsd-update fetch install genügen. Das hab ich auch gemacht und er updatete das Basissystem erfolgreich. Werden da eigentlich nur Sicherheitsaktualisierungen oder auch Softwareupdates mitinstalliert?
Dann habe ich Bash instaliert mit pkg_add -r bash installiert. Bevor ich das gemacht habe, habe ich allerdings das eine 8-stable-Quelle als Standart-Quelle ausgewählt und ein portsnap update und ein portsnap extract gemacht.

Danach habe ich die Ports (wie ich am Anfang meinte) upgegradet, mit portmaster -a. Anstatt nur bash und dessen Abhängigkeiten zu aktualisieren hat mir der Portmeister zusätzlich noch Bibliotheken und andere Pakete des Basissystems geupgradet. Zudem brauchte er noch ca. drei Stunden, um Dokumentationen von diversen Sprachen zu upgraden. Diese Dokus konnte ich selbstverständlich nicht mit pkg_delete loswerden, weil sie zum Basissystem gehören. Was ich ausserdem auch noch bemerkt habe ist, dass er die Software nicht von den Freebsd-Quellen sondern von den häuslichen Seiten der Software geupgradet hat. Das war wohl auch der Grund, wieso jetzt (5 Tage später) freebsd-update keine Updates mehr liefert. portmaster hat alles auf den aktuellsten Stand gebracht, sowohl Basissystem als auch Ports sowie die Dokus. Auf den aktuellsten, sicher aber auch nicht auf den stabilsten...

Sind Basissystem und Ports wirklich getrennt?
Ist es richtig, dass man für die Pakete auch einen Portupgrader (z.B. portmaster) verwenden muss (z.B. ein pkg_update)?

Kann mir jemand die Rätsel mit dem portmaster erklären?

 

[waki87]

Hallo zusammen

Irgendwie kommt mir das mit dem Portmanagement unlogisch vor...
Angeblich sollen Basisystem und Ports getrennt sein.
Für den Update des Basissystems soll angeblich ein freebsd-update fetch install genügen. Das hab ich auch gemacht und er updatete das Basissystem erfolgreich. Werden da eigentlich nur Sicherheitsaktualisierungen oder auch Softwareupdates mitinstalliert?

In der Regel nur Sicherheitsupdates. Details gibt’s in den jeweiligen Advisories: http://www.freebsd.org/security/advisories.html

Dann habe ich Bash instaliert mit pkg_add -r bash installiert. Bevor ich das gemacht habe, habe ich allerdings das eine 8-stable-Quelle als Standart-Quelle ausgewählt und ein portsnap update und ein portsnap extract gemacht.

Jetzt vermischst du ein paar Sachen: Es gibt einen Portstree für alle Versionen von FreeBSD. Mit portsnap holst du dir, anders als bei OpenBSD z.B., immer eine aktuelle Version.
Paketquellen spielen dann eine Rolle, wenn du pkg_add statt Ports benutzt. Es gibt Release-Quellen, die Pakete vom ungefähren Stand des Portstrees zum Zeitpunkt des jeweiligen Releases enthalten (dieselben Pakete sind auch auf der CD/DVD). Dann gibt es die Stable/Current-Quellen, die sich darum bemühen, möglichst aktuelle Pakete zu haben. Allerdings hinken die manchmal auch hinter den Port her.

Danach habe ich die Ports (wie ich am Anfang meinte) upgegradet, mit portmaster -a. Anstatt nur bash und dessen Abhängigkeiten zu aktualisieren hat mir der Portmeister zusätzlich noch Bibliotheken und andere Pakete des Basissystems geupgradet.

Das waren keine Bibliotheken des Basissystems, sondern Ports.

Zudem brauchte er noch ca. drei Stunden, um Dokumentationen von diversen Sprachen zu upgraden. Diese Dokus konnte ich selbstverständlich nicht mit pkg_delete loswerden, weil sie zum Basissystem gehören.

Nicht wirklich. Du kannst die Dokumentationen zwar als »distribution set« mitinstallieren, geupgradet werden sie aber in der Regel über Ports. Löschen solltest du die Pakete trotzdem können (*-freebsd-doc-*).

Was ich ausserdem auch noch bemerkt habe ist, dass er die Software nicht von den Freebsd-Quellen sondern von den häuslichen Seiten der Software geupgradet hat.

Woher er sich die distfiles holt, kann dir doch egal sein. Hauptsache, die Checksum stimmt.

Das war wohl auch der Grund, wieso jetzt (5 Tage später) freebsd-update keine Updates mehr liefert.

Moooment. Freebsd-update ist dazu da, das Basissystem zu updaten. Und dafür hat es seit 8.0-RELEASEp2 (6.1.2010) keine Updates mehr gegeben.

portmaster hat alles auf den aktuellsten Stand gebracht, sowohl Basissystem

Nein. Portmaster rührt das Basissystem nicht an.

als auch Ports sowie die Dokus. Auf den aktuellsten, sicher aber auch nicht auf den stabilsten...

Was den Portstree angeht, der ist momentan (noch) stabil. Wir sind sozusagen im Auge des Hurricanes zwischen libpng- und Xorg/KDE/Gnome-Update. =D
Das Basissystem ist in der Regel sehr stabil. Ich habe zum Beispiel den STABLE-Entwicklungszweig laufen und hatte nie Probleme. Bei einem RELEASE würde ich das noch viel weniger erwarten.

Sind Basissystem und Ports wirklich getrennt?

Ja.

Ist es richtig, dass man für die Pakete auch einen Portupgrader (z.B. portmaster) verwenden muss (z.B. ein pkg_update)?

Ein Port ist im Grunde nichts anderes als ein selbstkompiliertes Paket, das mit pkg_add installiert wird. Daher kannst du selbstverständlich auch neueste Pakete installieren, ohne sie selbst zu kompilieren. Sehr nützlich für das Upgraden bereits vorhandener Pakete ist pkg_upgrade aus sysutils/bsdadminscripts.

 

[pit234a]

Den Ausführungen von waki87 ist absolut nicht zu widersprechen.
Er erklärt das alles gut.
Weil ich gerade eben eine ähnliche Diskussion in anderem Umfeld über das, was ein Basis-System überhaupt darstellt führte, bin ich noch ein wenig sensibel.
Was ich lernen musste ist, dass die zugehörigen Begriffe nahezu frei und vollkommen unverbindlich genutzt werden. Es ist vielleicht unter deiner Würde, trifft diese Anfrage auch wirklich nur am Rande, aber in einer Art Artikel zum Thema legte ich den Gebrauch für mich fest: http://weispit.eu/make_me_unix.pdf
Wie gesagt, nicht für dich und nicht passend zu deiner Frage, aber doch vielleicht hilfreich im Überflug und hinsichtlich der Zuordnung der Begriffe.

Was nun folgt entspricht der Namensgebung, die ich da wählte und es wird sicher nicht Widerspruchsfrei bleiben.
FreeBSD ist keine Distribution und die Ports gehören nicht wirklich zu FreeBSD und haben im Grunde nichts damit zu tun.
FreeBSD ist gerade eben eine Kombination aus Kernel und Userland und bietet damit ein unixartiges (Posix-konformes) Betriebssystem für unterschiedliche Rechnerplattformen. Die Grundinstallation dürfte heute wohl bei etwa 250MB liegen, doch das ist ein Bauchwert, ich habe den nicht geprüft.
Darin enthalten ist auch eine shell und zahlreiche Tools, die dem Anwender einen Umgang mit dem System ermöglichen. Die wenigsten Nutzer wollen dabei stehen bleiben, sondern sie suchen weitergehende SW und möchten die installieren. In der Unix-Welt passiert das in der Regel aus den Quellen der gewünschten SW und das ist leider nicht immer einfach und manchmal beinahe unmöglich, es erfordert sehr spezielles Wissen. Hierbei stehen FreeBSD nahezu alle Quellen offen, denn es beherrscht nicht nur die notwendigen Technologien, es ist auch Dank seines Freien Lizenz-Modells sehr gut in der Lage, SW einzubinden, die ganz unterschiedlich geschützt ist. Es gibt keine Bedenken, CDDL geschützte SW in einem FreeBSD zu integrieren, was ein Unterschied zu GNU/Systemen ist, die sich sehr fest an der GPL orientieren.
Jedenfalls kann jemand, der weiß wie das geht, nahezu alle SW aus vorhandenen Quellen in ein FreeBSD System einbauen. Weil das nicht alle können und der Vorgang sehr zeitraubend ist, bietet FreeBSD zwei Vereinfachungen für Anwender an: Ports und Pakages.
Ich bin dafür sehr dankbar!
Bei den Ports handelt sich dann um eine Sammlung von SW, die einfach in ein FreeBSD eingebaut werden kann, weil hier die Bauanleitungen und Pfade zu den Quellen hinterlegt sind. Es sind genau genommen mehrere Pfade hinterlegt und auch die Quersummen der benötigten Dateien. Es wird dann, wenn diese Vereinfachung genutzt wird, automatisch nach einer gültigen Quelle gesucht, diese heruntergeladen, die Quersummen gebildet und verglichen und die Anwendung nach vorbestimmten Kriterien kompiliert, wobei es dann, wenn dies möglich ist, eine einfache Liste mit Optionen gibt, die der Anwender bestimmen kann. Dabei geht die Vereinfachung sogar so weit, dass Abhängigkeiten automatisch aufgelöst und fehlende SW nachinstalliert wird.
Die Installationsroutinen sind standardisiert: es genügt fast immer der einfache Aufruf von make install clean und die möglichen Optionen (make config) werden automatisch aufgerufen und vorgelegt. Vielleicht verdeutlicht ein Beispiel dies.
# cd /usr/ports/multimedia/vlc && make config
ruft die Optionen auf.
# cd /usr/ports/multimedia/vlc && make install clean
lässte die Optionen ebenfalls aufrufen und installiert dann vlc gemäß der gewählten Optionen UND installiert die benötigten Abhängigkeiten, zusätzliche SW um etwa die Optionen zu erfüllen.
Ist nun vlc aus den angegebenen Quellen gebaut worden und mit den gewünschten Optionen versehen, kann daraus ein Binärpaket erzeugt werden. Solch ein Paket entspricht genau dem gewählten Zustand für die kompilierte Quelle. Es hat genau diese Optionen und passt genau für diese eine Rechnerplattform. Solch ein Paket kann geschnürt werden und einem anderen verfügbar gemacht werden, der dann die Arbeit der Konfiguration und vor allem des Kompilierens spart. Mit einem einzigen Befehl wird solch ein Paket sehr schnell entpackt und eingearbeitet.
Das erledigt pkg_add.
pkg_add kann mehr, es kann auch auf entfernte Pakete zugreifen und auch notwendige Abhängigkeiten auflösen! Dies ist also die zweite große Erleichterung in einem FreeBSD, denn es werden zahlreiche fertig kompilierte Pakete angeboten, die sehr einfach und schnell eingebaut werden können. Alle Pakete sind aus den Ports gebaut worden.

Seit nicht allzulanger Zeit schuf Kamikaze eine Alternative zu pkg_add, die ich auf einem PC nutzte und die sehr überzeugend war. PKG_UPGRADE(1) zeigt dazu die nötigen Informationen und weiterführende Einträge in anderen Man-Pages. Die Intension ist (er möge mich korrigieren) tatsächlich die theoretischen Möglichkeiten eines pkg_add zu realisieren. In der Praxis gibt es nämlich immer wieder ungelöste Konflikte, die dazu führen, dass schließlich nicht Pakete verwendet werden, weil irgendwelche Versionen nicht passen und dann stattdessen aus den Quellen, also aus den Ports installiert werden muss. Wie geagt ist das sehr einfach mit FreeBSD, aber auch langwierig. Die Alternative von Kamikaze verspricht tatsächlich ausschließlich mit Paketen klar zu kommen und auf meinem PC tat es das auch. Dazu gibt es einige sinnvolle Optionen und auch Update-Funktionallität für alle installierten Pakete. Aus meiner beschränkten Erfahrung heraus würde ich dies empfehlen, wenn nicht spezielle Optionen notwenig oder gewünscht sind.

 

[TayTay]

Hallo zusammen

Vielen Dank für die ausführlichen Antworten. Jetzt ist bei mir das Unklare klar geworden.

Ich habe zum Beispiel den STABLE-Entwicklungszweig laufen und hatte nie Probleme. Bei einem RELEASE würde ich das noch viel weniger erwarten.

Wie kann man von RELEASE zum STABLE wechseln (ich meine jetzt das Basissystem)?


Kann man unter FreeBSD eigentlich zur Optimierung der Installation der Ports auch einfach wie unter Gentoo die /etc/make.conf bearbeiten? Also z.B. so:

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
MAKEOPTS="-j2"


Kümmert sich pkg_upgrade um alles? Also kann ich den Befehl ausführen und er lädt die neusten Pakete runter und installiert sie? Von welcher Quelle?

 

[pit234a]

kurz gesagt:
die man-pages zu:
freebsd-update
make.conf
pkg_upgrade
pkgtools.conf
die Datei /usr/local/etc/pkgtools.conf der Befehl printenv sowie die Datei /etc/csh.cshrc oder /etc/profile oder die jeweils lokalen Pendants der User.

Ich glaube wirklich, dass diese Seiten alles schön erklären und nicht mehr viel hinzugefügt werden muss.
freebsd-update ist ein script, dass sehr hilfreich ist, um das Basis-System auszutauschen oder upzudaten. Ich empfehle es vor allen anderen Möglichkeiten, aber es ist trotzdem nicht ganz unproblematisch. Die man page sagt ziemlich alles dazu. Die /etc/freebsd-update.conf gehört dazu und es gibt eine eigene man freebsd-update.conf und die erklärt auch verständlich.

Die Orte, wo nach Paketen gesehen wird, stehen in globalen Variablen. Die werden auch Environment Variabeln genannt und printenv zeigt, was da gerade eingestellt ist. Es gibt dabei unterschiedliche Variablen, die unterschiedliche Bedeutung haben. PKG_SITES ist etwa eine Liste von möglichen Orten, PACKAGESITE ist "der" Ort und PACKAGESITE_MIRRORS wohl wieder eine Liste.
Der Gebrauch der PKG_SITES ist vielleicht am flexibelsten. /usr/local/etc/pkgtools.conf enthält diese Liste. Solche Variabeln können auch direkt aus der Konfiguration der Shell gesetzt werden und Systemweit in der /etc/csh.cshrc (etc/profile) gemacht werden. Die csh... wird von csh oder tcsh genutzt, profile von bash.
setenv PKG_SITES ftp://ftp.freebsd.ch/pub/FreeBSD/releases/amd64/8.0-RELEASE/packages/Latest
wäre ein Eintrag für die cshrc, in der profile würde das glaube ich so aussehen:
PKG_SITES=ftp://ftp.freebsd.ch/pub/FreeBSD/releases/amd64/8.0-RELEASE/packages/Latest; export PKG_SITES
Jeder User hat eine solche Datei (.cshrc) in seinem Heimatverzeichnis und dort können diese Dinge dann auch gesetzt werden und die globalen Einstellungen ergänzen oder ersetzen.

Die man der make.conf und die Beispiele in /usr/share/examples/etc/make.conf erklären die Möglichkeiten ziemlich gut, außerdem gibt es einen lesenswerten Beitrag im Wiki. Die Optimierung hat eine leicht andere Sytax, als ich sie bei Linux-Systemen fand.
FORCE_MAKE_JOBS=yes
ist eine spezielle Möglichkeit, die Ports mit (ohje, mir fällt das Wort nicht ein, sagen wir mehreren Jobs gleichzeitig zu bauen und das gelingt noch nicht bei allen Ports aber schon bei sehr vielen. Ich setze das gewöhnlich und wenn es dann Fehler gibt, schalte ich es bewusst aus und lasse diese Ports dann wieder bauen. Die make.conf wird vor jedem Lauf neu eingelesen.
pkg_upgrade kümmert sich so ziemlich um alles. Lies die man-page, es gibt ausreichend Beispiele und Erklärungen darin. Die Dokumentation ist ausgezeichnet gemacht.

edit: ich hatte das nicht richtig verstanden. freebsd-update wechselt nicht von RELEASE zu STABLE. freebsd-update liest auf einem Server, wie etwa http://update4.freebsd.org/ welche Systeme es kann und dort stehen auch die Informationen, die für einen Wechseln benötig werden. Da ist kein STABLE dabei. Da würde ja auch in Windeseile die Anzahl der Einträge wachsen und unüberschaubar werden, wenn STABLE da auch eingepflegt würde. Wenn STABLE wirklich ist, was du willst und brauchst, dann folge dem Handbuch.

 

[waki87]

Eine ausführliche Anleitung gibt’s hier: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html (überhaupt sollte das Handbuch immer deine erste Anlaufstelle sein).

Die CFLAGS lassen sich genau wie unter Gentoo global in der make.conf festlegen. Allerdings ist zu beachten, daß einige Ports von Haus aus schon eigene CFLAGS benutzen. Die Standard-Flags sind -O2 -fno-strict-aliasing -pipe.

Mit pkg_upgrade -a werden alle Pakete über einen der offiziellen FTP-Mirrors auf den neuesten Stand gebracht.

 

[SolarCatcher]

Hi pit234a,

vielleicht findest Du das Haarspalterei von mir, aber zu sagen, ein FreeBSD sei "keine Distribution" ist schon etwas missverständlich, denn "BSD" steht ja für "Berkely Software Distribution".

Aber ich verstehe natürlich was Du meinst: Du hast die üblichen Linux-Distributionen im Sinn... und dann gebe ich Dir recht.

Gruß
SolarCatcher

 

[Kamikaze]

...
Kann man unter FreeBSD eigentlich zur Optimierung der Installation der Ports auch einfach wie unter Gentoo die /etc/make.conf bearbeiten? Also z.B. so:

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
MAKEOPTS="-j2"

...

Kümmert sich pkg_upgrade um alles? Also kann ich den Befehl ausführen und er lädt die neusten Pakete runter und installiert sie? Von welcher Quelle?

Erst mal zu den Optimierungen, das macht FreeBSD für dich automatisch. Es macht überhaupt keinen Sinn da etwas einzustellen. Ich habe sehr intensiv die GCC Doku studiert um festzustellen, dass die meisten Tipps in diese Richtung absoluter Blödsinn sind.

Was pkg_upgrade betrifft, das verwendet die gleichen Umgebungsvariablen wie pkg_add. Wenn die nicht vorhanden sind verwendet es recht sinnvolle Standardeinstellungen. Um es zu verwenden musst du sysutils/bsdadminscripts installieren. Was das Programm hervorhebt ist der Umgang mit Konflikten, das macht es meiner Meinung nach deutlich besser als portupgrade oder portmaster.

Die Manual-Page hat da auch ein paar sehr schöne Beispiele zu.

 

[Tronar]

Was das Programm hervorhebt ist der Umgang mit Konflikten, das macht es meiner Meinung nach deutlich besser als portupgrade oder portmaster.

Ich habe kürzlich mein 8.0-RELEASE mittels pkg_upgrade auf den Stand der aktuellen Heft-CD von freeX gebracht, was sich zwar auch 8.0-RELEASE nennt, was aber neuere Pakete mitbringt. Insbesondere bringt es auch Binärpakete von KOffice, das ich auf meinem alten Computer niemals kompilieren könnte. Soweit die Werbung. ;-)
Was mir nicht gefiel, war dieses quälend lange Scannen der Paketliste, bevor die Installation endlich losging. Und weil die Installation ein paarmal wegen Konflikten steckenblieb, d. h. pkg_upgrade ausstieg und nach Beseitigung des Hindernisses wieder neu gestartet werden mußte, durfte ich das sogar wiederholt genießen.
Gibt es denn keine Möglichkeit, diese Vorarbeiten abzukürzen, z. B. durch Anlegen temporärer Dateien?
Ansonsten ist das Skript aber eine feine Sache, wirklich!

 

[Kamikaze]

Ich habe noch nie erlebt, dass pkg_upgrade wegen einem Konflikt ausgestiegen ist? Das macht es eigentlich nur, wenn man das explizit so mit -X (aka --exit-on-conflict) startet. Das einzige was ich mir vorstellen kann ist, dass du den falschen Index verwendet hast, nämlich den von den FreeBSD Servern, statt dem, der zu den Paketen von freeX gehört.

Eine Abkürzung der Vorarbeiten ist nicht möglich, wirklich alles an Informationen wird gecacht (wie schreibt man das Wort korrekt auf Deutsch?). Was für dich bei einem großen Upgrade ein paar nervige Minuten sind, waren beim ersten funktionierenden Prototyp noch über 4 Stunden auf einem Core2Duo mit 2.4GHz.

Ansonsten fängt pkg_upgrade erst mit der Installation an, wenn es alle Abhängigkeiten kennt und die genaue Installationsreihenfolge aufgrund dieser Abhängigkeiten weiß, alle Pakete heruntergeladen (ich vermute mal du hast PACKAGESITE korrekt gesetzt um die Pakete von der CD zu verwenden, dann wird dieser Schritt übersprungen). Außerdem wird noch überprüft ob alle Pakete gültige tar-Archive sind, bevor die Installation startet. Diese letzte Prüfung wollte ich mal abschaffen, weil ich das für ein theoretisches Problem hielt, bis es mir dann tatsächlich mal passiert ist.

Kurz gesagt, wenn es endlich loslegt sollten eigentlich alle Fehlerquellen ausgeschlossen sein. Der einzige Schwachpunkt ist, dass sich pkg_upgrade 100% auf den INDEX verlässt. Wenn da etwas nicht stimmt, kann das Programm seine Aufgabe einfach nicht erfüllen.

 

[Tronar]

Ich habe noch nie erlebt, dass pkg_upgrade wegen einem Konflikt ausgestiegen ist? Das macht es eigentlich nur, wenn man das explizit so mit -X (aka --exit-on-conflict) startet. Das einzige was ich mir vorstellen kann ist, dass du den falschen Index verwendet hast, nämlich den von den FreeBSD Servern, statt dem, der zu den Paketen von freeX gehört.

-X habe ich beim ersten Lauf verwendet, aber auch beim zweiten ohne -X blieb er stehen. Das ist jetzt zwei Wochen her, und ich weiß viele Details nicht mehr, z. B. die Fehlermeldung. Wird denn der INDEX nicht automatisch von dort geholt, wohin $PACKAGESITE weist? Das hatte ich auf die DVD gerichtet.

Eine Abkürzung der Vorarbeiten ist nicht möglich, wirklich alles an Informationen wird gecacht (wie schreibt man das Wort korrekt auf Deutsch?). Was für dich bei einem großen Upgrade ein paar nervige Minuten sind, waren beim ersten funktionierenden Prototyp noch über 4 Stunden auf einem Core2Duo mit 2.4GHz.

Minuten waren es nicht, sondern grob zwei Stunden auf einem (Single-)Pentium 1600 mit 400 MHz FSB. Wenn die Info "gecachet" (sic?) wird (im Speicher?), dann war sicher Speichermangel der Grund dafür (256 MB). pkg_upgrade hatte insgesamt ca. 150 meiner Pakete zu aktualisieren. Vielleicht spielt es auch eine Rolle, daß die DVD kein vollständiges Repository darstellt, d. h., viele der Pakete, die ich instaliert hatte, waren auf der DVD gar nicht zu finden und sicherlich auch nicht im INDEX.

Kurz gesagt, wenn es endlich loslegt sollten eigentlich alle Fehlerquellen ausgeschlossen sein. Der einzige Schwachpunkt ist, dass sich pkg_upgrade 100% auf den INDEX verlässt. Wenn da etwas nicht stimmt, kann das Programm seine Aufgabe einfach nicht erfüllen.

Ich finde es ja prima, daß pkg_upgrade auf Nummer Sicher geht, keine Frage! Und ich weiß auch nicht, ob die INDEX auf der DVD ganz astrein war. Letztendlich hat es auch geklappt. Wenn ich so was wieder mal tue, werde ich daran denken, alles sauber mitzuprotokollieren.

 

[Kamikaze]

-X habe ich beim ersten Lauf verwendet, aber auch beim zweiten ohne -X blieb er stehen. Das ist jetzt zwei Wochen her, und ich weiß viele Details nicht mehr, z. B. die Fehlermeldung. Wird denn der INDEX nicht automatisch von dort geholt, wohin $PACKAGESITE weist? Das hatte ich auf die DVD gerichtet.

Hmm, weißt du noch den genauen Pfad auf den du PACKAGESITE gerichtet hast? Und ob auf der DVD überhaupt ein INDEX vorhanden war?

Minuten waren es nicht, sondern grob zwei Stunden auf einem (Single-)Pentium 1600 mit 400 MHz FSB. Wenn die Info "gecachet" (sic?) wird (im Speicher?), dann war sicher Speichermangel der Grund dafür (256 MB).

Das entspricht genau meinem Testrechner (P4 1.6GHz, 256MB Ram) und sollte deutlich schneller gehen. Möglicherweise hat das Prüfen der Pakete von der DVD so viel Zeit gekostet.

pkg_upgrade hatte insgesamt ca. 150 meiner Pakete zu aktualisieren. Vielleicht spielt es auch eine Rolle, daß die DVD kein vollständiges Repository darstellt, d. h., viele der Pakete, die ich instaliert hatte, waren auf der DVD gar nicht zu finden und sicherlich auch nicht im INDEX.

Was nicht im INDEX ist wird komplett ignoriert.

Ich finde es ja prima, daß pkg_upgrade auf Nummer Sicher geht, keine Frage! Und ich weiß auch nicht, ob die INDEX auf der DVD ganz astrein war. Letztendlich hat es auch geklappt. Wenn ich so was wieder mal tue, werde ich daran denken, alles sauber mitzuprotokollieren.

Ich schätze ich müsste mir diese DVD mal ansehen um das alles zu beurteilen. Bekommt man da irgendwo ein Image her?

Du könntest mir auch deine /var/log/pkg_upgrade.log zukommen lassen.

 

[Tronar]

Hallo, Kamikaze!

Zunächst mal sorry für die späte Antwort; ich bin vor dem Wochenende zu nix gekommen!

Hmm, weißt du noch den genauen Pfad auf den du PACKAGESITE gerichtet hast? Und ob auf der DVD überhaupt ein INDEX vorhanden war?

# l /mnt/packages
00README.html
All/
INDEX
INDEX-8
accessibility/
(...)

Ich bin nicht mehr sicher, ob ich $PACKAGESITE auf /mnt/packages oder auf /mnt/packages/All gerichtet hatte.

Das entspricht genau meinem Testrechner (P4 1.6GHz, 256MB Ram) und sollte deutlich schneller gehen. Möglicherweise hat das Prüfen der Pakete von der DVD so viel Zeit gekostet.

Mein CD-Laufwerk ist einigermaßen schnell, das war nicht der Flaschenhals.

Ich schätze ich müsste mir diese DVD mal ansehen um das alles zu beurteilen. Bekommt man da irgendwo ein Image her?

Das ist problematisch. Ich bin gerade im Ausland und habe keine besonders schnelle Internetverbindung. Und die freeX-Ausgabe ist auch nicht mehr die aktuelle, das Folgeheft ist bereits erschienen; man müßte es also beim Verlag bestellen. Rechtlich gesehen darf ich es wohl auch nicht öffentlich zugänglich machen, sondern nur als "Privatkopie" weiterreichen.

Du könntest mir auch deine /var/log/pkg_upgrade.log zukommen lassen.

Ist angehängt als pkg_upgrade.txt.

In der freeX steht noch der Satz: "Ein kleiner Teil der Pakete meldet bei der Installation Warnungen mit Versionkonflikten, die ignoriert werden können, einige wenige Pakete können nicht installiert werden, wenn konkurrierende vorher eingespielt worden sind, und brechen ab."

 

[Kamikaze]

Ich bin nicht mehr sicher, ob ich $PACKAGESITE auf /mnt/packages oder auf /mnt/packages/All gerichtet hatte.

Dann erübrigt sich die Sache mit der Performance, denn er hat alle Pakete aus dem Netz geladen:

pkg_upgrade(8)
     If the packages are locally available (e.g. over NFS) the fetching (and
     duplicating) of packages can be avoided by setting the environment vari-
     able PACKAGES to the package tree and setting PACKAGESITE to "$PACK-
     AGES/Latest".

Ich schaue mir aber mal wegen den Konflikten den Log an. Ich gehe davon aus, dass er den INDEX von der FreeX verwendet hat aber die Pakete aus dem Netz (das würde bei /mnt/packages/All zumindest passieren). Dann ist es zu erwarten, dass es knallt.

 

[Kamikaze]

Im Log steht immer wieder ERROR(7), das hat überhaupt nichts mit Konflikten zu tun:

PKG_UPGRADE(1)
     ERR_BACKUP_UNKNOWN 7
             There was an unknown error when backing up a package.

Im Quelltext steht dazu:

# Well, I've got no idea at all what else
# could go wrong. Too bad the return codes
# of pkg_create are not documented.

Wenn das Paket verschwindet oder nicht vollständig ist (letzteres erzeugt lediglich eine Warnung), wird das erkannt. Ich würde mal raten, dass kein Platz mehr auf der Partition frei war auf der die Backups angelegt wurden.

 

[Tronar]

Hallo, Kamikaze!

Zunächst mal: die Pakete wurden nicht aus dem Netz gezogen. Auf der DVD existiert zwar kein "Latest"-Verzeichnis, aber ich konnte ihn irgendwie überreden, von DVD zu installieren. Im Netz gibt es doch gar nichts anderes als 8.0-RELEASE, dann hätte ich jetzt auch keine neueren Pakete auf der Platte.
Meine bruchstückhaften Erinnerungen helfen Dir natürlich nicht viel. Nur als kleiner Verbesserungsvorschlag: Man könnte vielleicht die Anforderungen an die Verzeichnisstruktur etwas liberaler gestalten bzw. konfigurierbar machen. Eigentlich benötigt man ja nur ein INDEX-File und ein x-beliebiges Verzeichnis, in dem die Pakete sind.

Ich würde mal raten, dass kein Platz mehr auf der
Partition frei war auf der die Backups angelegt wurden.

Klar! Er wollte die Backups nämlich auf die DVD machen, da war kein Platz frei.
Das war aber nicht die Ursache der "ERROR"-Zeilen, sonst wären die ja bei jedem Paket zu sehen. Vielmehr sind das tatsächlich die Stellen, an denen er stehen blieb. Der zeitliche Abstand (1 h) zeigt, daß ich weiter oben etwas übertrieben habe. Ich gab lediglich ein: "pkg_delete -f", "pkg_add" und wieder "pkg_upgrade", um dann jeweils eine Stunde bis zum erneuten Installationsbeginn zu warten. (Später ging es etwas schneller, als das meiste schon erledigt war.)

 

[Kamikaze]

Der Standardort für das Backup ist /usr/ports/packages/pkg_upgrade-backup.

Und glaub mir, ein Problem mit den Backups war die Ursache, es gibt nämlich nur eine Stelle im Code, die den Fehler zurück gibt.

Was PACKAGESITE angeht, da habe ich noch mal nachgesehen, da sollte /mnt/bla/All tatsächlich auch funktionieren, weil er einfach das letzte Verzeichnis entfernt und All dafür dran hängt.

 

[rakso]

hallo!

was ist denn nun die beste / einfachste / fehler- sprich abhängigkeitstoleranteste möglichkeit bzw software zum portupdaten? ich habe damit nämlich schlechte erfahrungen in erinnerung (glaueb portupgrade war das) und möchte jetzt alles auf meinem server mal updaten.. habe immernoch schiss davor, dass es dabei alles zerhaut und man dann nie wieder updates etc richtig machen kann.

habe 7.2-stable

 

[Tronar]

Der Standardort für das Backup ist /usr/ports/packages/pkg_upgrade-backup.

Völlig unabhängig von allen Optionen und Umgebungsvariablen?

Und glaub mir, ein Problem mit den Backups war die Ursache, es gibt nämlich nur eine Stelle im Code, die den Fehler zurück gibt.

Ein Vorschlag: Wenn ich am Wochenende etwas Zeit habe, werde ich
a) zwei, drei beliebige Pakete der "richtigen" 8.0-RELEASE aus dem Internet installieren,
b) diese Pakete dann mittels pkg_upgrade von besagter DVD upgraden und alles fein protokollieren
c) und vielleicht noch einen Konflikt herbeiführen, um zu sehen, ob er aussteigt. (Aber wie?)

Erst mal vielen Dank für Deine Bemühungen
Tronar

 

[Kamikaze]

Nein, du kannst PACKAGES (Standard ist /usr/ports/packages) in der make.conf setzen, dann kommen die Backups wo anders hin.

Ich schätze es läuft darauf hinaus, dass ich die Bedeutung der Fehlernummern aus dem C-Code fischen muss.

 

[Tronar]

So, gestern abend habe ich mal ein kleines Spiel installiert, die Internetverbindung getrennt und dann die besagte DVD zum Updaten verwendet. Das sieht dann so aus:

# mount -t cd9660 /dev/acd0 /media
# setenv PACKAGES /media/packages
# setenv PACKAGESITE /media/packages/All
# pkg_upgrade -v -a
Synchronize the local index copy with the package server.
Make a list of outdated packages.
Perform dependency checks.
Sort packages by dependency.
Validate downloaded packages.
Install 1 package(s).
===> Update <ltris-1.0.12_1,1> to <ltris-1.0.13,1> (games/ltris)
mkdir: /media/packages/pkg_upgrade-backup: Read-only file system
tar: Failed to open '/media/packages/pkg_upgrade-backup/ltris-1.0.12_1,1.tbz'
pkg_create: make_dist: tar command failed with code 256
pkg_upgrade: Ignoring incomplete backup of <ltris-1.0.12_1,1>.
pkg_add: warning: package 'ltris-1.0.13,1' requires 'libmikmod-esound-3.1.11_2',
but 'libmikmod-3.1.11_2' is installed
=> Update <ltris-1.0.12_1,1> to <ltris-1.0.13,1> (games/ltris) succeeded

Das Ganze hat jetzt nur so gute 15 min gedauert. War ja nur ein Paket.
Ist das verträglich mit dem Verhalten Deines Testrechners?
Die DVD lief nur am Anfang und am Ende, ansonsten stand sie still.
Er versucht, wie Du siehst, das Backup nach /media/packages/pkg_upgrade-backup/ zu schreiben, was zu einer harmlosen Fehlermeldung führt. Die Installation wird trotzdem erledigt. (Ich hatte, glaube ich, damals noch "-b" angegeben, worauf er auch noch meckerte, daß er das nicht vorhandene Backup nicht löschen könne.)
Das abhängige Paket habe ich dann auch noch erneuert:

# pkg_upgrade -v libmikmod-esound
Synchronize the local index copy with the package server.
Make a list of outdated packages.
Perform dependency checks.
Sort packages by dependency.
Validate downloaded packages.
Install 1 package(s).
===> Update <libmikmod-3.1.11_2> to <libmikmod-esound-3.1.11_2> (audio/libmikmod)
mkdir: /media/packages/pkg_upgrade-backup: Read-only file system
tar: Failed to open '/media/packages/pkg_upgrade-backup/libmikmod-3.1.11_2.tbz'
pkg_create: make_dist: tar command failed with code 256
pkg_upgrade: Ignoring incomplete backup of <libmikmod-3.1.11_2>.
pkg_delete: package 'libmikmod-3.1.11_2' is required by these other packages
and may not be deinstalled (but I'll delete it anyway):
sdl_mixer-1.2.8_2
ltris-1.0.13,1
=> Update <libmikmod-3.1.11_2> to <libmikmod-esound-3.1.11_2> (audio/libmikmod) succeeded

Auch wieder 'ne Viertelstunde.

Ein Konflikt trat aber eben nicht auf. Wie ich das erreiche, ohne mir mein halbes System umzukrempeln oder stundenlang herumzusuchen, weiß ich jetzt nicht. Vorschläge sind willkommen.

Ich schätze es läuft darauf hinaus, dass ich die Bedeutung der Fehlernummern aus dem C-Code fischen muss.

Jetzt mach Dich nicht verrückt, solange ich nichts Genaueres liefern kann!

Übrigens: Das Logfile wurde nur um je eine Zeile erweitert:
1272223228 - Sun Apr 25 21:20:28 CEST 2010 - DONE: Update <ltris-1.0.12_1,1> to
<ltris-1.0.13,1> (games/ltris)
1272224503 - Sun Apr 25 21:41:43 CEST 2010 - DONE: Update <libmikmod-3.1.11_2> t
o <libmikmod-esound-3.1.11_2> (audio/libmikmod)

 

[Kamikaze]

Das ist jetzt mal interessant. Anscheinend gibt pkg_create den gleichen Fehlercode zurück, wie wenn das alte Paket nicht vollständig ist und pkg_upgrade läuft weiter (wenn das alte installierte Paket beschädigt ist, sollte man es ja erst recht ersetzen).

Nach deinem Log würde ich aber sagen, es gibt manchmal einen anderen Fehlercode zurück, dann knallt's.

Um das zu vermeiden würde ich ein
# mount_nullfs -o union TMPDIR /media/packages

machen, dann kann pkg_upgrade ungestört die Backup Dateien anlegen. Wenn das schief geht und pkg_upgrade weiterläuft, kann pkg_upgrade sonst halt auch kein richtiges Rollback mehr machen.

Jetzt wäre noch interessant, welcher Schritt ungefähr wie lange gedauert hat:
Make a list of outdated packages.
Perform dependency checks.
Sort packages by dependency.
Validate downloaded packages.
Install 1 package(s).

Wenn das ganze 15 Minuten dauert geht da mächtig etwas schief. Selbst auf einem langsamen Rechner sollte das einfach Updaten eines einzelnen Pakets (bis er mit dem Validieren anfängt zumindest) nicht länger als eine Minute dauern.

 

[Tronar]

Das ist jetzt mal interessant. Anscheinend gibt pkg_create den gleichen Fehlercode zurück, wie wenn das alte Paket nicht vollständig ist und pkg_upgrade läuft weiter (wenn das alte installierte Paket beschädigt ist, sollte man es ja erst recht ersetzen).

Nach deinem Log würde ich aber sagen, es gibt manchmal einen anderen Fehlercode zurück, dann knallt's.

Da, wo es knallte, waren es richtige Inkompatibilitäten. Ein Paket konnte nicht installiert werden, solange ein anderes Paket da war. Keine frühere Version (die hatte er ja mit pkg_delete -f gelöscht), sondern ein ganz anderes Paket, das ich eben von Hand löschen mußte. (pkg_upgrade -X war mir nicht geheuer.) Weil also pkg_add nicht funktionierte, wollte er ein Rollback machen und fiel mangels Backup-Paket auf die Nase. Ich glaube, ich hab's kapiert.

# mount_nullfs -o union TMPDIR /media/packages

Gute Idee! Aber wie gesagt, ich müßte erst mal so einen Konflikt provozieren können.

Jetzt wäre noch interessant, welcher Schritt ungefähr wie lange gedauert hat:
Make a list of outdated packages.
Perform dependency checks.
Sort packages by dependency.
Validate downloaded packages.
Install 1 package(s).

Das weiß ich noch ungefähr. Der erste Schritt (das ist doch der mit der Anzeige "Checking <Paketname>"?) ca 10 min, der zweite (dependency) 5 min. Der Rest war ein Klacks.
Ich habe auch auf CPU- und Speicherauslastung geschaut: CPU unter 5 %, Speicher ca. 190 von 256 MB, auch da war also noch Luft. Aber die Festplatte ratterte permanent.

Langsam frage ich mich, ob ich nicht ein ganz anderes Problem auf meinem Rechner habe, das mit Deinem Skript nicht das geringste zu tun hat.

 

[Kamikaze]

OK, das ist zu lahm. Da muss ich noch mal optimieren. Mit der nächsten Version werden alle Algorithmen greedy, das heißt es wird keine unnötige Arbeit mehr gemacht. Bisher ist das Konzept etwas zusätzliche Arbeit in Kauf zu nehmen, weil es insgesamt deutlich schneller geht alles auf einmal zu machen (greedy ist ohne Objekte die das Kapseln zu komplex).

Was sein könnte ist, dass dein Arbeitsspeicher so klein ist, dass /var/db/pkg und der INDEX zusammen nicht komplett gecacht werden. Bei diesen Vorarbeiten werden das komplette /var/db/pkg und der komplette INDEX abgerufen. In diesem Fall wären die greedy-Algorithmen natürlich deutlich schneller.

Pakete werden übrigens immer mit pkg_add -f installiert. Das sollte eigentlich nie scheitern so lange genug Platz auf der Platte ist und das Paket nicht beschädigt ist. Ich kann mir wirklich keinen Konfliktfall vorstellen, den pkg_upgrade nicht selbst handhabt. Es kann natürlich sein, dass es die gibt, aber mir fällt nichts plausibles ein.