Port installationen brechen ab....

Das Editoren auf Consolenbasis schlecht mit DOS-Editoren vergleichbar sind, liegt schlichtweg daran, dass Unix (bis heute) als Console zig verschiedene Terminals unterstützt (damals in der Regel über V24 angebunden). Da gab es halt nicht nur VT100 und VT2xx die schon recht konfortabel waren, sondern auch VT52 und noch wesentlich schlimmer ausgestattete Röhren mit 26+ Tasten. vi hatte immer den Vorteil auf einer 26+ Tasten zu laufen, weil ESC und CTRL gabs dort halt.

DOS konnte in der Regel schon auf ANSI.SYS (oder den Direktzugriff auf den 80x25 Buffer der Graka) und auf eine Taste mit mind. 84 Keys verlassen. Da lassen sich halt andere Editoren bauen.

vi, ee und andere lassen sich heute immer noch wunderbar über V24 (oder TCP/IP) schieben...
 
es ist nahezu ausgeschlossen, dass es derartige Abbrüche wegen Version-Missmatch gibt, wenn du alles "richtig" gemacht hast.
Wenn du den Portstree aktuell hast (was ja angeblich der Fall war) und wenn du nicht von sonstwoher (evtl aus dem Installationsmedium) schon was anderes installiert hattest. Dabei brechen Installationen normalerweise nicht ab oder lassen sich trotzdem durchführen, wenn die vorgefundene Version älter ist, als die zu installierende.

Nun bin ich beileibe kein Guru, deshalb warne ich vorweg.
Doch, nach einer Installation des Systems und vor der Installation weiterer Software würde ich dringend eine Aktualisierung des kompletten Systems empfehlen. Dazu nutze ich zwar immer noch portupgrade und mache dann etwas in der Art von portupgrade -acfk ,doch, pormaster ist moderner und daher eher zu empfehlen. portupgrade baut auf eine Datenbank und die muss dann intakt sein, sprich, die Versionen und ihre Abhängigkeiten werden dort bereinigt. Bei Verwendung von portupgrade und einem Abbruch, wird ein entsprechender Hinweis geliefert, dass pkgdb erst durchlaufen werden muss. Dies kann und sollte vielleicht auch vor dem Start von portupgrade bei größeren Aufgaben ohnehin gemacht werden.

Wenn du nur einen einzelnen Port mittels make install clean installierst, werden keine Datenbanken und Versionen gecheckt. Das ist nicht tragisch. Aber es werden dann auch keine Konflikte gelöst, nur angemeckert, nicht mal Lösungen vorgeschlagen.

Also, nach Installation des Grundsystems erst einen portsnap fetch update und dann einen Neubau dessen, was du schon hast (was reichlich wenig sein sollte an der Stelle) und dann erst den Aufbau des Systems aus den Ports und damit das schneller geht und nicht so viel Aufmerksamkeit braucht, mit einem der dafür vorgesehen Tools, nicht mit make install clean für jeden einzelnen Port.
Danach wieder den tree aktualisieren (es kann ja Tage dauern, bis das so weit installiert ist, was man alles will), dann wieder alles neu durchbauen lassen (wieder Tage) und das vielleicht nochmal. Dann hast du dein System durchgängig auf dem aktuellen Stand und bei regelmäßigen Updates bleiben die Deltas gering und sind recht gut zu bewältigen.
Dann kannst du auch einzelne Anwendungen unbedenklich aus den Ports hinzunehmen und es wird wohl fast immer gelingen, ohne Versionen als falsch zu kritisieren.
 
Elwood schrieb:
Das Editoren auf Consolenbasis schlecht mit DOS-Editoren vergleichbar sind, liegt schlichtweg daran, dass Unix (bis heute) als Console zig verschiedene Terminals unterstützt (damals in der Regel über V24 angebunden). Da gab es halt nicht nur VT100 und VT2xx die schon recht konfortabel waren, sondern auch VT52 und noch wesentlich schlimmer ausgestattete Röhren mit 26+ Tasten. vi hatte immer den Vorteil auf einer 26+ Tasten zu laufen, weil ESC und CTRL gabs dort halt.

DOS konnte in der Regel schon auf ANSI.SYS (oder den Direktzugriff auf den 80x25 Buffer der Graka) und auf eine Taste mit mind. 84 Keys verlassen. Da lassen sich halt andere Editoren bauen.

vi, ee und andere lassen sich heute immer noch wunderbar über V24 (oder TCP/IP) schieben...
Zum Vergrößern anklicken....

Das erklärt natürlich einiges, Danke dafür!
Die Zeiten habe ich nicht aktiv miterlebt, kenne nur Tatstaturen mit 102 bzw. 105 Tasten. Man kann das ganze wohl wieder unter der Rubrik " heilige Kuh: Abwärtskompatibilität" betrachten :)

@Lord_x
Den Nano schaue ich mir mal an, danke für den Tip.

@pit234a
Ich blicke noch nicht ganz durch, was ich alles bei meine ersten Gehversuchen Falsch gemacht habe, aber wie heist es so schön: Aus Fehlern lernt man, selbst dann wenn man die Fehler nicht kennt.
Ich war bei meinen ersten Installationen davon ausgegangen, daß die Ports aktuell sind, wenn ich den kompletten Portstree ziehe, daß dem nicht ganz so ist, habe ich jetzt auch mitbekommen. (ein Portsnap fetch update nach einem portsnap fetch extract hatte tatsächlich noch was zu aktualisieren)

Ich habe teilweise dann den/die angemeckerten Port(s) manuell via "make deinstall" deinstalliert, damit diese vom Hauptport neu installiert werden können (teilweise mit gleicher Version, und teilweise mit neuerer Version).
Daß das nicht der richtige Weg ist, habe ich mitlerweile auch mitbekommen / erlesen (man soll auch Ports mit PKG Deinstall deinstallieren)

Mit Paketen hatte ich Anfänglich kaum zu tun, da das "Pkg_ Repo" ja immer noch Offline ist - ausser den PBIs von PCBSD.


Was ich immer noch nicht ganz begriffen habe, wie Port und Paketmanagement zusammenarbeiten.
Ich versuch daß mal aufzudröseln, wie ich das bislang verstanen habe:

PKG_ (Alt) bekommt von Portinstallationen nichts mit >> Daher werden Abhängikeiten im Paketmanagment nicht vollstandig verfolgt. Aus diesem Grund sollte man Paket und Portinstallationen nicht mischen.

PKG2NG soll auch Portinstallationen verfolgen und in die eigene Datenbankstruktur übernehmen (ist das schon umgestezt, oder kommt das erst noch?)

Aber wie werden die Abhängigkeiten verfolgt und gepflegt, wenn man gänzlich alles aus dem Portstree via make install (clean) installiert (was natürlich extrem Zeitaufwendig ist)?
Ich denke, daß ich genau an dieser Stelle gegen die Wand gelaufen bin, bei den PCBSD Installationen inkl. KDE - ich habe nämlich keine Info, wie denn das "Grundsystem" hier installiert wird, bzw. wie dieses aufgebaut wurde.
Es gibt nur einen Fortschrittsbalken, der bei 100 % fertig ist, nach dem Reboot begrüsst einen ein fast komplett eingerichtets System, nur noch Bildschirmauflösung einstellen, Root Passwort vergeben und 'nen User einrichten.

Insgesamt ist es zur Zeit so, daß ich mehr lese als aktiv am System zu arbeiten.
Gefühlt bin ich jetzt ohne GUI (KDE) schon weiter als vorher mit - die "Alten Hasen" haben doch meistens recht!

Und nehmt mein Meckern Bitte nicht ganz so ernst, auch wenn ich da manchmal etwas Provokant-Sarkastisch auftrete - versucht immer das Augenzwinkern zu erkennen :-)
 
Das mit pkg und pkgng ist so nicht richtig. Ich glaube ich muss dringend den entsprechende Wiki-Artikel aktualisieren.
 
Ich benutzte früher JED editor oder joe s editor in der Konsole. Sind sehr einfach zu bedienen.
Heute nur noch Gedit.
 
Kamikaze schrieb:
Das mit pkg und pkgng ist so nicht richtig. Ich glaube ich muss dringend den entsprechende Wiki-Artikel aktualisieren.
Zum Vergrößern anklicken....

ich stelle mir eine Gegenüberstellung der möglichen Verfahren vor, wo dann alle möglichen Befehle gelistet und erklärt sind. Dabei kann man vielleicht Eigenschaften vergeben, wie etwa: pflegt diese oder jene Datenbank | bezieht die Abhängigkeiten von hier oder dort | und so weiter.
KA ob das realisierbar ist, aber tatsächlich wächst mir das auch über den Kopf und ich hätte sehr gerne ein Nachschlagewerk.

Das Handbuch (englisch) zeigt immerhin nun pkgng und erklärt was dazu.
Ganz aktuell scheint es mir nicht zu sein. Die Schwierigkeiten, keine Pakete zu haben, sind zB gar nicht erwähnt.

Nun habe ich nicht das Wissen, so etwas selbst zu basteln und es hat sich in der Vergangenheit gezeigt, dass Aufrufe meist ohne Resonanz verhallen. Das ist schade, weil wir doch alle OpenSource nutzen.
Das könnte bedeuten, dass so ein Projekt mal wieder an dir kleben bleibt und das finde ich nicht in Ordnung.

Können wir das als Thread starten und "Wahrheit" sammeln und dann in passende Form bringen?
Wahrscheinlich mangels Beteiligung nicht.
Vielleicht kannst du das organisieren und erklären, was zum Füllen des Artikels fehlt und dann finden sich vielleicht Helfer, die einen kleinen Part übernehmen?
 
@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!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben