1000 Wege zum Ports updaten?

T

testit

Well-Known Member
Hi,

ich komme momentan ein wenig durcheinander, was die beschriebenen Möglichkeiten betrifft, die ports upzudaten.

Folgende Varianten scheint es zu geben, wobei mich mal interessieren würde, ob es hier irgendwelche Vorteile/Nachteile der jeweiligen Variante gibt:

Variante A)
# cd /usr/ports
# make update

Variante B)
portsnap fetch update

Variante C)
cvsup -g -L 2 /etc/[Dein_cvsupfile]
2. cd /usr/ports && make fetchindex
3. portsdb -u
4. pkgdb -u

Danke und Gruss
testit
 
testit schrieb:
Variante A)
# cd /usr/ports
# make update
Zum Vergrößern anklicken....
Macht ein "cvsup -g -L 2 /etc/[Dein_cvsupfile]" wenn du die entsprechenden Variablen in deiner make.conf gesetzt hast.
Man kann aber auch ueber die make.conf es so einstellen das bei einem "make update" portsnap fetch; portsnap update aufgerufen wird.
 
Ich benutze: "cd /usr/ports && make fetchindex" In verbindung mit angepasster /etc/make.conf & src, cvsup & docfiles. Findest du alles sauber dokumentiert im Wiki.
 
Hi,

danke Dir, aber eine Frage noch:

Ist das normal, dass nach portnap fetch die Meldung:
Applying patches... done.
Fetching 13823 new ports or files...
erscheint und "ewig" lange sich nichts mehr tut?

Gruss
testit
 
Beim ersten fetch - ja. Was 'make update' macht hängt davon ab, was du in deiner make.conf eingetragen hast. Das kann entweder portsnap oder cvsup aufrufen.
 
Wie nur bestimmten Port-Zweig updaten?

Hallo,

kann mir jemand sagen, wie ich nur einen bestimmten Port updaten kann, ohne zuvor ein komplettes portsnap laufen zu lassen, bevor ich portupgrade verwende?

Bsp.: /usr/ports/applikation soll mittels portupdate upgedatet werden.

Es soll zuvor allerdings kein portsnap gestartet werden, der ALLE ports aktualisiert, sondern es soll nur sichergestellt werden, dass ein portupdate von /usr/ports/applikation die aktuelle Version berücksichtigt.

Danke und Gruss
testit
 
Das ist mit cvsup möglich, aber eine heikle Angelegenheit, da der Portstree inkonsistent wird.
 
Zuletzt bearbeitet:
Ich kann mich da nur Kamikaze anschliessen. Was spricht dagegen den ganzen portstree zu aktualisieren, testit? Unter normalen Bedinungen (keine Ende eines Portsfreeze *g* ) bei einem Udateintervall von einer Woche dauert es mit portsnap nicht wirklich lange. Je nach Geschwindigkeit so zwischen 1-5min.

Weil wenn zum Beispiel ein port aus /ports/applikation beim upgraden einen anderen neuen port aus .z.B. ports/devel als dependency benötigt dann könnte es etwas problematisch werden.

Wenn du selber eigene ports entwickelst und testest gibt es auch Möglichkeiten, deine Änderungen vor möglichen Überschreibungen zu schützen.
 
testit schrieb:
Hi,


unter http://www.daemonology.net/portsnap/ ist beschrieben, dass nur ein portsnap update gemacht werden muss (anstelle von fetch update).

Offenkundig muss doch erst der Snap geholt werden, bevor mit dessen Hilfe upgedatet werden kann.

Was ist denn nun korrekt?

Gruss
testit
Zum Vergrößern anklicken....

D.h.

beim ersten mal ausführen von portsnap ist die reihenfolge: fetch -> extract -> update


Danach reicht es aus wenn du jedes mal folgendes ausführst: portsnap fetch update
 
Also ich habe da auch so meine Probleme:confused:

Ich habe ein BSD 5.4 System und betreibe damit einen Trac Server der version 0.8 und Subversion 1.1.3.
Jetzt wollte ich alles auf den neuesten Stand bringen und habe den Weg über portsnap gewählt:
Code: 
          portsnap fetch
          
          portsnap extract

Das lief aller wunderbar. Das Portsystem hatte ich vorher schon installiert. Ich dachte, dass ich damit aber sicherstelle einen konsistenten Porttree zu haben.

Danach habe ich das Update gestartet:

Code: 
          portupgrade -a

Das lief auch durch und seit dem läuft mein Webserver nicht mehr richtig und es wurden auch nicht alle Pakete auf den neuesten Stand gebracht. Das konnte ich mit
Code: 
            pkg_version -v
ermitteln. Wenn ich jetzt wieder portupgrade einsetze, so meckert es über Inkonsistenzen, die ich nicht auflösen kann.

Ich bin jetzt am überlegen das ganze System neu zu installieren und direkt nach der Installation den Porttree auf den neuesten Stand zu bringen und danach nicht mehr anzufassen. Das ist zwar aber nicht der Sinn der Sache und deshalb bin ich unsicher.

Was meint Ihr denn so?
 
Wenn nach einerm 'portupgrade -a' nicht alle Pakete auf dem neusten stand sind, heißt das, dass nicht alles fehlerfrei kompiliert wurde - Portupgrade ist da sehr informativ. Was die Inkonsistenzen betrifft; hast du schon mal gemacht was dort vorgeschlagen wird? Lass einfach mal 'pkgdb -F' laufen.
 
Ja. Das habe ich probiert. Ich kann sie aber nicht auflösen, weil mir das dafür notwendige Hintergrundwissen fehlt.

Ich habe die Maschine nicht verfügbar um mehr Details zu nennen. Wie kann ich denn die Meldungen aus meinem
Code: 
portupgrade
sichten?

Wenn so Sachen passieren, dann kann ich den
Code: 
portupgrade
aber auch nicht automatisieren, um das System auf dem neuesten Stand zu halten. Die Idee macht aber gerade den Reiz des Portsystems für mich aus.
 
Gibt es ein eigentlich eine generelle Vorgehensweise zum Auflösen solcher Konflikte?

Ich denke, dass der Porttree inkonsistent ist, wenn ich solche Probleme bekomme. Ich glaube nicht, dass es an meiner Maschine liegen kann, es sei denn es ist ein Fehler beim Übersetzen aufgetreten, der abhängig von der Maschine ist. Ich hatte aber bis jetzt nie solche Probleme. Es war nisher immer auf die falsche Version einer Bibliothek oder einem Programm zurückzuführen.

Weiß da jemand was?
 
klhesc schrieb:
...
Wenn so Sachen passieren, dann kann ich den portupgrade aber auch nicht automatisieren, um das System auf dem neuesten Stand zu halten. Die Idee macht aber gerade den Reiz des Portsystems für mich aus.
Zum Vergrößern anklicken....
Wenn ich so was lese bekomme ich immer Angst-Zustände.
Wie kommt man nur auf die Idee einen Server automatisch ohne wenigstens ports/UPDATING gelesen zu haben, updaten lassen zu wollen?!

Dat macht man doch nicht :grumble:
 
Tja... Irgendwie habe ich geglaubt, dass es halt geht. ;'( Ich gebe ja auch zu, dass ich kein FreeBSD Experte bin.

Von meiner Naivität und Unwissenheit mal abgesehen würde mich aber immer noch interessieren was denn als Best Practice angesehen wird, solche Probleme zu lösen? Soll ich die einzelnen Pakete versuchen zu installieren und dann sehen was schief läuft? Und was dann?

Das mit dem pkgdb -F hat nicht wirklich geholfen? Gibt es da noch Tipps zu?
 
Normalerweise musst du wenn du New Dependency auswählst einfach den gleichen Paketnamen eintippen (ohne Versionsnummer). Dann kannst du TAB drücken und siehst was alles mit dem gleichen Namen drin ist. Dann nimmt man normalerweise das gleiche Paket mit höherer Versionsnummer.

In den meisten fällen schlägt pkgdb schon das richtige vor. Wenn eine Dependency mit einer gleichen Names, blos mit anderer Versionsnummer ersetzt werden soll, ist alles in Ordnung.

Wenn Ports fehlschlagen gehe ich meistens so vor, daes ich schaue was noch gebaut werden muss (ie. mit pkg_version oder portupgrade -an und dem entsprechenden grep darüber).

Dann versuche ich die Ports nochmal einzeln mit
# portupgrade -rR category/port

auf den neusten Stand zu bringen. Weiteres Vorgehen dann je nach Problem.
 
Vielen Dank.

Das werde ich mal ausprobieren!!!:)

In Zukunft werde ich dann nach der Installation des Basissystems von CD als erstes portsnap und portupgrade installieren und dann
Code: 
portsnap fetch
portsnap extract
portupgrade -a
port_version -v
ausführen. Zu dem Zeitpunkt sollte sehr wenig installiert sein, sodass es die wenigsten Probleme geben sollte. Dann muss nur noch der Porttree konsistent sein und es sollte klappen.:D ...oder???:confused:
 
Ja, sollte funktionieren. Nur den Befehl port_version kenne ich nicht. Wahrscheinlich meinst du pkg_version.

Falls du portsnap verwendest ist dein Index immer auf dem aktuellen stand, deshalb kannst du

# pkg_version -Iv

verwenden, das ist deutlich schneller.
 
Das mit dem pkgdb -F hat jetzt wohl geklappt.

Natürlich habe ich jetzt ein neues Problem. Wenn ich folgendes Kommando eingebe:

Code: 
a# pkg_version -v
apache-2.0.53_1                     =   up-to-date with port
apr-nothr-db4-1.0.1_1               <   needs updating (port has 1.2.7_1)
autoconf-2.53_3                     =   up-to-date with port
autoconf-2.59_2                     =   up-to-date with port
automake-1.9.6                      =   up-to-date with port
bash-3.1.16                         =   up-to-date with port
bsdiff-4.3                          =   up-to-date with port
clearsilver-python-0.10.3           =   up-to-date with port
db42-4.2.52_3                       <   needs updating (port has 4.2.52_4)
expat-2.0.0_1                       =   up-to-date with port
freebsd-sha256-20050310             =   up-to-date with port
gettext-0.14.5_2                    =   up-to-date with port
gmake-3.80_2                        =   up-to-date with port
help2man-1.36.4_1                   =   up-to-date with port
libiconv-1.9.2_2                    =   up-to-date with port
libtool-1.3.5_2                     =   up-to-date with port
libtool-1.5.10_1                    <   needs updating (port has 1.5.22_2)
libtool-1.5.22_2                    =   up-to-date with port
m4-1.4.4                            =   up-to-date with port
/libexec/ld-elf.so.1: Shared object "libexpat.so.5" not found, required by "httpd"
[: -le: argument expected
/libexec/ld-elf.so.1: Shared object "libexpat.so.5" not found, required by "httpd"
[: -le: argument expected
mod_python-3.2.8                    =   up-to-date with port
neon-0.25.5                         =   up-to-date with port
p5-gettext-1.05_1                   =   up-to-date with port
perl-5.8.8                          =   up-to-date with port
pkgconfig-0.15.0_1                  =   up-to-date with port
portsnap-1.1                        =   up-to-date with port
portupgrade-2.0.1_2,1               =   up-to-date with port
py24-PySQLite-1.0.1                 =   up-to-date with port
py24-pysqlite-2.0.7_1               =   up-to-date with port
python-2.4.3                        =   up-to-date with port
ruby-1.8.4_8,1                      =   up-to-date with port
ruby18-bdb1-0.2.2                   =   up-to-date with port
sqlite-2.8.17_1                     =   up-to-date with port
sqlite-3.3.5                        =   up-to-date with port
subversion-python-1.1.3             <   needs updating (port has 1.3.1_1)
swig-1.3.29_2                       =   up-to-date with port
tcl-8.4.11,1                        =   up-to-date with port
trac-0.9.5                          =   up-to-date with port
a#

Wo kommen denn die Zeilen
Code: 
/libexec/ld-elf.so.1: Shared object "libexpat.so.5" not found, required by "httpd"
[: -le: argument expected
/libexec/ld-elf.so.1: Shared object "libexpat.so.5" not found, required by "httpd"
[: -le: argument expected
her. Das sieht doch aus wie eine Fehlermeldung beim übersetzen.

Weiß da jemand was???:confused:
 
Die ist bei einem Update verschwunden (aktuell ist libexpat.so.6). Trage einfach

libexpat.so.5 libexpat.so

in deine /etc/libmap.conf ein.
 
Da wäre ich nie drauf gekommen:)

Jetzt sind die Meldungen weg und ich kann mich daran machen die restlichen Ports auf den neuesten Stand zu bringen.

Vielen Dank! Ich bemühe mich in Zukunft auch etwas zurückzugeben (Wenn ich mal was weiß:rolleyes: )
 
Ich gebe ja auch zu, dass ich kein FreeBSD Experte bin.
Zum Vergrößern anklicken....
Jeder fängt mal klein an. Aber auf dem Weg zum FreeBSD-Experte helfen Dir viele Internetseiten, Handbücher, Benutzerforen und Anleitungen. Zum Beispiel findest Du im BSDForen-Wiki einige ausführliche Artikeln zum hier besprochenen Thema:

http://wiki.bsdforen.de/index.php/FreeBSD_-_Ports_und_Programme_aktualisieren
http://wiki.bsdforen.de/index.php/FreeBSD_-_Ports
http://wiki.bsdforen.de/index.php/FreeBSD_-_cvsup_in_einem_Rutsch
http://wiki.bsdforen.de/index.php/FreeBSD_-_Packages_und_Programme_richtig_deinstallieren
http://wiki.bsdforen.de/index.php/Make.conf_optimieren
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben