@Digi-Quick
Wenn ich richtig empfinde, können wir diesen Post nun wohl beenden?
Ich glaube, während dieses Beitrages hast drei mal das System gewechselt und/oder neu installiert. Da kennt sich natürlich kein Schwein mehr aus. Die neuen Probleme durchkreuzen dann die alten und niemand weiß mehr, was eigentlich gelöst werden sollte.
Also, ich habe ir jetzt nur behalten, dass ich folgendes noch in dem Zusammenhang mit dem Portstree sagen wollte:
der ändert sich mitunter stündlich!
Das ist also gar kein fester Baum, der nicht mehr lebt.
Mit portsnap fetch extract ziehst du einen komprimierten, also für kurze Zeit eingefrorenen Zustand des Baumes und entpackst den auf deinem System.
Mit portsnap fetch update ziehst du die neuen Updates zu deinem Baum, also das Delta zwischen dem, was auf deinem System liegt und dem, was im Netz aktuell steht.
In einer gewissen Zeitspanne ist der Baum aus dem extract identisch zu dem aktuellen Baum im Netz. Doch bereits innerhalb der Zeit, die ein Update braucht, hat sich die Situation allermeist verändert und es gibt Neuigkeiten auf dem Portstree.
Bestandteil des Baumes ist die /usr/ports/UPDATING und die sollte vor jedem update, also wenigstens vor jedem größeren Update gelesen werden. Meist macht das niemand und jeder versucht, die Lösungen selbst zu finden. manchmal gelingt es, manchmal kommt man Zähne-knirschend auf einen entsprechenden Eintrag zurück und immer wäre es sehr viel einfacher gewesen, hätte man nur erst gelesen und das auch richtig gemacht, was dort erklärt wird.
Also, nochmal: die UPDATE wird genau zum Baum im Netz dort laufend erneuert und dann auf deinen PC überspielt, wenn du einen portsnap fetch update ausführst und dir damit den aktuellen Port abholst.
Nun schwimme ich etwas, weil ich es nicht ganz genau weiß, aber die Abhängigkeiten sind in den INDEX Dateien gelistet, die auch unter /usr/ports zu finden sind und natürlich dann auch jedesmal angepasst werden.
Code:
nagios-check_smartmon-20100318_1|/usr/ports/net-mgmt/nagios-check_smartmon|/usr/local|Nagios plug-in to get status from smartmontools|/usr/ports/net-mgmt/nagios-check_smartmon/pkg-descr|ports@bsdserwis.com|net-mgmt|gettext-0.18.1.1_1 libiconv-1.14_1 python27-2.7.3_6|gettext-0.18.1.1_1 libiconv-1.14_1 python27-2.7.3_6 smartmontools-6.1||||
nagios-check_tftp-1.0.1|/usr/ports/net-mgmt/nagios-check_tftp|/usr/local|Nagios plugin to check tftp servers|/usr/ports/net-mgmt/nagios-check_tftp/pkg-descr|holgerrepp@googlemail.com|net-mgmt||bash-4.2.42 gettext-0.18.1.1_1 libiconv-1.14_1 tftp-hpa-5.2|http://mathias-kettner.de/download/check_tftp|||
Dies ist ein Auszug aus meiner INDEX8 und den habe ich nun einfach mal irgendwo mitten heraus geschnitten. An anderer Stelle hier im Forum habe ich mir mal mehr Mühe gegeben und die Beispiele besser gewählt und die Erklärung ein kleines bisschen vertieft. Warum nun da auch INDEX7 und INDEX6 in /usr/ports existiert, das weiß ich nicht genau. Sicher sind darin die Abhängigkeiten der Ports in den entsprechenden Vorläufern von FreeBSD8 enthalten, aber, wozu die nun gebraucht werden, ist mir nicht ganz klar.
Als nächstes kann es eine INDEX-*.db geben, eine Datenbank zu den Ports, die du installiert hast. Diese Datenbank ist ähnlich der, die unter /var/db/pkg für Binärpakete der alten Art angelegt worden war.
Diese Datenbank ist rein lokaler Natur, sie wird von den entsprechenden Installations-Mechanismen (etwa portinstall) genutzt und gepflegt und zu Beginn auch angelegt. Es erfolgt (ich kenne nicht alles! aber bei portupgrade ist es wohl so) ein Abgleich zu der Paketdatenbank in /ver/db/pkg.
Es ist in FreeBSD nicht genau so, wie in OpenBSD, wo vor einer Installation aus den Ports erst ein Binär-Paket fertig geschnürt und dieses dann erst installiert wird, aber es ist ganz ähnlich und der Verweis kann vielleicht helfen, das Verhalten unter FreeBSD zu verstehen. Hier wird nicht automatisch ein Paket auch tatsächlich gebaut (das ist eine mögliche Option), aber irgendwie wird so getan, als sei die SW aus den Ports ein Paket gewesen und sie wird mit ihrer Version genau so eingetragen und sie kann genau wie ein Paket später gelöscht werden (und sollte dies auch).
Die Aussage, Pakete und Ports nicht zu mischen, bezieht sich nun zum größten Teil darauf, dass es überhaupt nicht gelingt. (meine Auslegung)
Uuuhps?
Es gibt Versionskontrollsysteme und die warnen davor, wenn falsche Versionen zueinander gemischt werden sollen. Falsch ist bei Ports, wenn es nicht genauso in der INDEX gelistet ist. Das bedeutet nicht, dass eine Anwendung nicht trotzdem gut laufen wird, aber im allgemeinen wollen wir da lieber vorsichtig sein. Deshalb verhindern die verschiedenen Systeme eine derartige Installation zunächst und das auch mit Recht.
Ein Sysadmin kann derartige Restriktionen mit entsprechenden Optionen umgehen, die jeweiligen Installations-Programme sind flexibel genug.
Es kann aber auch gründlich misslingen!
Deshalb macht so etwas ein Automatismus nicht von alleine, sondern es gibt eine Fehlermeldung. Die allereinfachste ist die, die hier mal zu Anfang gezeigt wurde, dass nämlich ein installiertes Programm zu alt ist und ersetzt werden müsste.
Alle SW, die aus Binärpaketen installiert wird, ist grundsätzlich älter, als jene in den Ports und auch da kann es schon zu solchen Missverhältnissen kommen, dass eine ältere SW installiert ist, als sie nun vom Port vorausgesetzt wird.
In solchen Fällen ist es bei FreeBSD und auch bei anderen Systemen üblich, den Sysadmin darauf hinzuweisen, dass hier bereits eine ältere Version vorhanden ist und deshalb nicht die neue ohne konkretes Kommando eingebaut werden wird. Der Sysadmin sieht sich das an und entscheidet, was er haben möchte. Der Sysadmin ist ein wirklich wichtiger Kollege!!!
In aller Regel wird er dazu neigen, die alte SW durch neue SW zu ersetzen.
Das macht er manuell, seinen Wunsch kann kein Automatismus voraus ahnen.
Also, der Hinweis, dass eine ältere Version bereits vorhanden ist, ist eine der Standard-Meldungen und vielleicht die am allereinfachsten zu lösende.
Die Strategie wird ja angesagt: lösche erst den alten Port und installiere dann den neuen.
Wenn ein make install bis zu diesem Fehler durchläuft, ist das ein verdammt gutes Zeichen, denn dann gab es keine anderen Fehler und es kann fast immer ganz getrost der alte Port mit make deinstall entfernt und der neue mit make install clean eingebaut werden. Es ist geradezu keine Fehlermeldung, sondern ein positives Feedback, dass ansonsten alles klar war und nur die alte Version den Einbau der neuen noch blockiert.
Also, ganz und gar nichts, das einen entmutigen sollte, ganz im Gegenteil!
