R
ralli
Guest
Zukünftig werde ich auch die Ports aktuell halten. Gibt es eine Empfehlung, in welchen Abständen ein portsnap update gefahren werden sollte?
foxit
Well-Known Member
Es gibt einen Head [1] Branch als auch einen für jedes Quartal [2].
Gruss
[1] https://svnweb.freebsd.org/ports/head/
[2] https://svnweb.freebsd.org/ports/branches/
Gruss
[1] https://svnweb.freebsd.org/ports/head/
[2] https://svnweb.freebsd.org/ports/branches/
pit234a
Well-Known Member
meine eigene: immer dann, wenn man ports bauen möchte, zuvor einen update machen.
So lange man den portstree nicht benutzt, ist es auch egal, welche Versionen lokal bei dir vorkommen.
Vor jedem Neubau eines Ports oder SW-Update würde ich unbedingt erst portsnap fetch update rufen.
Dabei kann es natürlich auch bewusst und gewollt sein, gerade noch eine alte Version zu bauen, die aber zum Rest des System passt. In solchen Fällen kann ein einfacher Bau eines neuen Ports ansonsten zu einer Orgie werden. Die lässt sich jedoch eh nicht lange vermeiden und hinauszögern, weshalb ich das als Ausnahme ansehe.
Pakete sind wesentlich gefälliger und daher extrem empfehlenswert.
Einzelne Ports, die man dann manuell baut (und auch gezielt und ohne etwa mit portmaster oder porupgrade auf Versions-Integrität zum Rest des Systems zu achten), sind gut zu handeln, weil man sie eh nur bei Bedarf erneuert. Beim pkg update bleiben sie wegen pkg lock unberücksichtigt. Wird dann eine neuere Version benötigt, kann man die ja nur erhalten, wenn zuvor auch der portstree aktualisiert wird.
Die Information von foxit ist natürlich wesentlich.
Mit portsnap läuft man nicht so leicht Gefahr, die "falschen Ports" zu nehmen, aber trotzdem schadet zweimal hinsehen nicht. Wenn jemand an den Systemvariablen experimentiert hatte und vielleicht unsauber hin- und hergeswitched war, könnte er eine Weile auf dem falschen Zweig segeln, bevor er das überhaupt bemerkt. Solche Fehler, wie hier im Thread beschrieben, sind da geradezu typisch.
Es gibt schon Fallstricke genug. Um das zu minimieren, bleibe ich nur noch auf RELEASE, wenn es nicht einen sehr guten Grund für eine andere Wahl geben sollte. Mit meiner HW gibt es keinen derartigen Grund für mich.
R
ralli
Guest
Danke an Euch für die Informationen. Dann bin ich ja für die Zukunft gewappnet.
R
ralli
Guest
Eine Ergänzung möchte ich noch hinzufügen. Heute habe ich alles neu installiert, Grundinstallation ohne Ports, dann portsnap fetch update, dann den nvidia-driver-340 aus den ports gebaut und alles konfiguriert. Nach einem Neustart des Rechners erkannte und lud der das Nvidia Modul nicht. Es wurde auch mit kldstat nicht angezeigt. Dann habe ich im entsprechenden port /x11/nvidia-driver-340 ein make clean install eingegeben und den Rechner erneut gebootet. Und dann funktionierte es. Warum das so ist, weiß der Teufel, ich jedenfalls weiß es nicht!
R
ralli
Guest
So, eine Nacht drüber geschlafen und ausgeruht erkenne ich, das das ganz alleine mein eigener Fehler war. Natürlich muß der Bau des Nvidia-driver-340 nach der Aktualisierung der Ports mit make install angestßen werden und nicht mit make allein. Aber ich hab aus allem gelernt, wie wichtig es ist, die Ports auf den neuesten Stand zu halten.
pit234a
Well-Known Member
du hattest oben geschrieben:
Angenommen, du machst kein make clean. Dann könnte es passieren, dass bei einem portsnap fetch update (oder SVN-Update) der komplette Baum zwar überschrieben wird und die Bauanleitungen für neuere Versionen eingepflegt werden, dass aber in den alten Bau-Verzeichnissen noch die Reste vom letzten Bau stehen und dann auch immer wieder berücksichtigt werden. Daher ist es recht wichtig, nach jedem erfolgreichen Bau oder abgeschlossenen Versuch, ein make clean loszulassen.
make install clean ist daher die im Handbuch und überall sonst empfohlene Befehlssequenz.
Wenn ein Bau aber fehlschlägt oder ich mal die Optionen ändern möchte, dann sollte (je nachdem) bewusst mit make clean zwischendurch aufgeräumt werden.
Dann macht deine Befehlskette make clean install durchaus Sinn. Nach Erfolg sollte dann nochmal ein make clean laufen.
Es gibt auch gute Tools zum Verwalten der Ports. portsmaster wird immer genannt und ich nutzte "damals" immer portupgrade und portsclean oder so ähnlich. Außerdem sind die bsdadminscripts von Kamikaze zu empfehlen.
Insgesamt braucht ein System (nach meiner bescheidenen Erfahrung) sehr viel mehr Wartungsarbeit, wenn es aus den Ports gebaut und weiter betrieben werden soll. Es ist nicht umsonst empfohlen, in einer sauberen Jail und mit poudriere zu arbeiten. Es kann sonst durchaus zur Qual werden, das System sauber und up to date zu erhalten. Naja, Qual für den Rechner, aber manchmal auch für den Anwender.
Für mich habe ich entschieden, dass ich das hinter mir gelassen habe und lieber auf Pakete setze. Für die zwei Ports, die ich nun manuell pflege, brauche ich keine zusätzlichen Verwaltungstools für die Ports. Ich finde es ein wenig schade, dass ich dafür überhaupt den kompletten Portstree an Bord nehmen musste, aber andererseits ist der manchmal auch sehr hilfreich, ohne dass man ihn weiter nutzt. Man kann so schnell (offline) mal nachsehen, was zu einem nicht installierten Port so geschrieben steht. Auf meinem kleinen Asus verzichte ich darauf vollkommen und lebe alleine mit Paketen.
und das funktioniert. Ich hatte gedacht, es sein ein Typo, aber es meint ja, dass zunächst gecleant und dann installiert wird. Das ist recht wichtig, wenn man manuell aus den ports baut.
Angenommen, du machst kein make clean. Dann könnte es passieren, dass bei einem portsnap fetch update (oder SVN-Update) der komplette Baum zwar überschrieben wird und die Bauanleitungen für neuere Versionen eingepflegt werden, dass aber in den alten Bau-Verzeichnissen noch die Reste vom letzten Bau stehen und dann auch immer wieder berücksichtigt werden. Daher ist es recht wichtig, nach jedem erfolgreichen Bau oder abgeschlossenen Versuch, ein make clean loszulassen.
make install clean ist daher die im Handbuch und überall sonst empfohlene Befehlssequenz.
Wenn ein Bau aber fehlschlägt oder ich mal die Optionen ändern möchte, dann sollte (je nachdem) bewusst mit make clean zwischendurch aufgeräumt werden.
Dann macht deine Befehlskette make clean install durchaus Sinn. Nach Erfolg sollte dann nochmal ein make clean laufen.
Es gibt auch gute Tools zum Verwalten der Ports. portsmaster wird immer genannt und ich nutzte "damals" immer portupgrade und portsclean oder so ähnlich. Außerdem sind die bsdadminscripts von Kamikaze zu empfehlen.
Insgesamt braucht ein System (nach meiner bescheidenen Erfahrung) sehr viel mehr Wartungsarbeit, wenn es aus den Ports gebaut und weiter betrieben werden soll. Es ist nicht umsonst empfohlen, in einer sauberen Jail und mit poudriere zu arbeiten. Es kann sonst durchaus zur Qual werden, das System sauber und up to date zu erhalten. Naja, Qual für den Rechner, aber manchmal auch für den Anwender.
Für mich habe ich entschieden, dass ich das hinter mir gelassen habe und lieber auf Pakete setze. Für die zwei Ports, die ich nun manuell pflege, brauche ich keine zusätzlichen Verwaltungstools für die Ports. Ich finde es ein wenig schade, dass ich dafür überhaupt den kompletten Portstree an Bord nehmen musste, aber andererseits ist der manchmal auch sehr hilfreich, ohne dass man ihn weiter nutzt. Man kann so schnell (offline) mal nachsehen, was zu einem nicht installierten Port so geschrieben steht. Auf meinem kleinen Asus verzichte ich darauf vollkommen und lebe alleine mit Paketen.
pit234a
Well-Known Member
und weil wir gerade dabei sind: der braucht die FreeBSD-System-Sourcen und entsprechend sollten (müssen) die dann auch vor jedem Bau aktualisiert werden, wenn sich da etwas getan hat. Das ist natürlich besonders für CURRENT so, aber es sollte halt im Blick bleiben und ist einer der Gründe, weshalb ich momentan lieber mit einem Fehler in meinem Treiber lebe, als den aus den Ports zu bauen. Das wäre zwar nicht kompliziert, aber die Pflege könnte aufwändiger werden, als ich das derzeit möchte.
Vielleicht entscheide ich auch wieder, weniger regelmäßig Updates zu nehmen, sie regen mich meist eh nur auf und dann wäre vielleicht auch der Bau mehrerer oder sogar aller Ports wieder eher ein Thema. Vielleicht aber auch erst mit einem neuen und schnelleren Rechner...
Wie auch immer, der Hinweis darauf, auch diese Quellen immer aktuell zu halten, sollte nun hier nicht fehlen.