Portupgrade Verstaendnis

lockdoc

lockdoc

Well-Known Member
Ich bin grade auch ein trauriger user mit folgendem Problem
Code: 
/libexec/ld-elf.so.1: Shared object "libpng.so.5" not found,

Und ja, ich habe mich schon ueberall durchgeklickt und lasse derzeit folgendes laufen:
Code: 
portupgrade -frk graphics/png


Ich haette dazu noch ein paar allgemeine Fragen (ist ja grad nix zu tun, da das Ding schon seit ueber einem Tag rattert):


Soweit ich das verstanden habe, werden hier (bei portupgrade -frk graphics/png) alle Ports neugebaut, die png als Abhaengigkeit haben.
1.1) Wird denn hier nur deren aktuell installierte Version neugebaut oder wird dann gleich die neueste Version neugebaut?​
1.2) Ist das das gleiche als wenn ich alle Ports neubaue, die ich via pkg_info -R png* aufgelistet bekomme?​


Da das Updaten ja unmenschlich lange dauert, wollte ich mal in mein Win%^%s booten (also mit <Ctrl>+<C> abbrechen).
2.1) Kann ich das so einfach abbrechen und er weiss dann, wo er weitermachen soll?
2.2) Also genau gefragt: Ist portupgrade so schlau zu wissen, welche er schon neugebaut hat und welche noch das Problem mit libpng.so.5 haben?

Es sieht so aus, dass waehrend dem Neubauvorgang einige Ports Probleme haben und nicht gebaut werden.
3.) Wird mir am Ende ein Bericht angezeigt, welche Fehlgeschlagen sind (mein Terminal Buffer ist leider begrenzt xD)?

Wird kein Bericht angezeigt wird und ist er auch nicht so schlau (wie bei 2. gefragt) nur die Ports neuzubauen, die noch Probleme mit libpng.so.5 haben.
4.) Wass kann ich dann machen um die restlichen (fehlgeschlagenen) Ports zu finden und neuzubauen?

5.) Werden bei portupgrade -a
a) nur veraltete Ports neugebaut​
b) werden hier grundsaetzlich alle Ports neugebaut​
c) werden hier nur veraltete und aktuelle Ports die nicht via "portupgrade -frk graphics/png" gebaut wurden, neugebaut?​

6.) Wofuer brauche ich und was genau macht ein: ？
Code: 
make build-depends-list

7.) Achso und wie finde ich raus welche Pakete ich nicht mehr benoetige?
+ habe ich jetzt 2 Versionen und beide Zweige (2er und 3er als Beispiel) wurden auf den neuesten Stand gebraucht, wie finde ich raus, ob ich den aelteren Zweig davon loeschen kann

8.) Gibs noch anderes Interessantes was man darueber wissen sollte?


Ich werde im Anschluss noch ein portupgrade -afk machen, ich hoffe mal dadurch wird das portupgrade -frk graphics/png nicht sinnlos :huth:


Antworten willkommen - hab mir solche Muehe bei der Formatierung gegeben:D
LG
 
Zuletzt bearbeitet:
lockdoc schrieb:
Soweit ich das verstanden habe, werden hier (bei portupgrade -frk graphics/png) alle Ports neugebaut, die png als Abhaengigkeit haben.
Zum Vergrößern anklicken....

Der portupgrade Schalter -k steht für keep-going, diesen Schalter würde ich nicht benutzen, so lange es sich irgendwie vermeiden lässt.
Denn das bedeutet, dass etwas kaputtes zurückbleiben kann.

Meine portupgrade Lieblingsschalter wären da:
Code: 
portupgrade -rfun graphics/png
um erst mal zu gucken, was alles gebaut würde, ohne es zu bauen.Sozusagen erst mal ein Leerdurchlauf. Dauert auch nicht lange.
Und dann den -n Schalter für noexecute weglassen, um das dann alles wirklich zu bauen:
Code: 
portupgrade -rfu graphics/png
Das kann entsprechend lange dauern.
Es gibt natürlich auch noch die Möglichkeit fertige Pakete zu verwenden, falls die Maschine etwas langsam sein sollte.
Hier gibt es Portupgrade Kniffe und Tipps zur Handhabung:
https://www.bsdwiki.de/Portupgrade_Kniffe_und_Tipps_zur_Handhabung

Um mal nach zu schauen, wie weit portupgrade ist, bei einer größeren Anzahl von zu bauenden Ports:
Code: 
ps aux | grep portupgrade
in ein freies Terminal eingeben.

Edit:
was den portupgrade -a Schalter für all betrifft: der baut nur das an Paketen neu, was veraltet ist.
Unterbricht man die Maschine beim Bau mit portupgrade -a, sollte nur die Compilerarbeit verloren gehen, vom Paket was sich gerade im Bau befindet.
Die jeweils von portupgrade -a bereits fertig gebauten und installierten Pakete sind ja bereits aktuell und in der Paketdatenbank registriert, die gehen auch beim shutdown nicht verloren.
Gegebenenfalls sollte man vor der portupgrade Fortsetzung mal pkgdb über die Paketdatenbank drüber gehen lassen:
Code: 
pkgdb -Ffv
Lieber einmal zu viel die Paketdatenbank streicheln als zu wenig. ;)
Direkt beim bearbeiten der Paketdatenbank sollte man die Maschine wohl in Ruhe ihre Arbeit verrichten lassen.
Also während portupgrade gerade ein Paket registriert würde ich es nicht stören, wenn es sich irgendwie vermeiden lässt.

Beim rekursiven portupgrade, zum Beispiel portupgrade -rfu graphics/png muss wieder von vorne angefangen werden, wenn die Maschine beim Bau gestört wird.
 
Zuletzt bearbeitet:
Danke Fusselbaer!

wie sieht es mit dem abbrechen denn bei
Code: 
portupgrade -frk graphics/png

Also wegen dem -f Schalter aus?

Hier baut er ja alle Pakete neu, auch wenn er sie schon "neu" sind. Merkt er sich denn, wenn man ihn mal gestartet hat und nun zwischendurch abbricht, was er schon getan hat, oder faengt er wieder von vorne an?

Ich muss mal dingend neustarten... :-(


Btw:
Code: 
ps aux | grep portupgrade
hatte erst kein output gekriegt, weil mein Terminalfenster zu klein war, also um auf nummer sicher zu gehen noch ein "w" ranhaengen.
 
Hallo lockdoc,

meine Erfahrung ist, dass Du Builds abbrechen kannst, solange ein port nur compiliert wird.
Befindet sich ein port im Installations-Prozess, solltest Du diesen noch abwarten bevor Du abbrichst.

Gruß,
[KB]
 
@[KB]

Du hasst mich ein wenig missverstanden. Mir geht es hier darum die Frage zu klaeren, ob portupgrade seine Arbeit wieder aufnimmt.
laut ps aux(w) | grep portupgrade werden 432 Ports neugebaut und derzeit ist die Machine at port 121.

Wenn ich nun neustarte, beginnt er dann wieder von 1 oder macht er bei 121 weiter?
Der -f Schalter sagt ja, dass er die Ports auch neubaut, wenn sie schon neu sind, darum ist das grade unklar fuer mich wie er sich verhalten wuerde...
 
lockdoc schrieb:
Wenn ich nun neustarte, beginnt er dann wieder von 1 oder macht er bei 121 weiter?
Der -f Schalter sagt ja, dass er die Ports auch neubaut, wenn sie schon neu sind, darum ist das grade unklar fuer mich wie er sich verhalten wuerde...
Zum Vergrößern anklicken....

Es geht wieder bei 1 los.
Übrigens würde ich den '-k' Schalter wirklich weglassen.

Da war noch 'ne Frage:
Es sieht so aus, dass waehrend dem Neubauvorgang einige Ports Probleme haben und nicht gebaut werden.
3.) Wird mir am Ende ein Bericht angezeigt, welche Fehlgeschlagen sind (mein Terminal Buffer ist leider begrenzt xD)?
Zum Vergrößern anklicken....
Ja.
 
X__________X

Man das ist so, als wenn man im Bus sitzt und pinkeln muss und der Fahrer kann nicht anhalten :-(

Aber Danke fuer die Info.

Btw, wie sieht es mit portmaster aus... ist der da schlauer?
 
Wieso eigentlich libpng.so.->5<- ? z.Zt. ist eigentlich libng.so.->6<- aktuell.
Der Port, der zu der Fehlermeldung führte, scheint schon *etwas* älter zu sein wenn er danach sucht !?
Portstree ist aktuell ??
 
Hmm also bei mir befindet sich auch eine /usr/local/lib/compat/pkg/libpng.so.5 unter dem Pfad, die auch entweder zu Compat5.x oder Compat6.x gehört. Liegt aber daran, dass ich das System immer wieder mit make buildworld aktuell gehalten habe und eine Abwärtskompatiblität gewährleisten wollte. Vieleicht ists ja auch bei lockdoc so. Müsste es mal runterhauen, bin aber nie dazu gekommen.
 
lockdoc schrieb:
Also wegen dem -f Schalter aus?

Hier baut er ja alle Pakete neu, auch wenn er sie schon "neu" sind. Merkt er sich denn, wenn man ihn mal gestartet hat und nun zwischendurch abbricht, was er schon getan hat, oder faengt er wieder von vorne an?

Ich muss mal dingend neustarten... :-(
Zum Vergrößern anklicken....

Den Schalter -k solltest du nicht nehmen. Der Schalter -f ist force also Gewaltsam wird dann ein Portupgrade von diesem Port durchgeführt. In Verbindung mit -rfa werden alle abhängigen Ports gebaut und der alte deinstalliert und der neue installiert. Das alles geschiet dann gewaltsam. Ein Abbruch des Vorgangs durch ein Neustart beginnt dann auch wieder von vorn neu zu bauen, wenn man den Befehl für den Port absetzt.

Code: 
portupgrade -rfa python27-2.7.1_1

Würde immer wieder den Port und seine Abhängigkeiten neu bauen. Egal wo man abbricht.
 
bluebyte schrieb:
Hmm also bei mir befindet sich auch eine /usr/local/lib/compat/pkg/libpng.so.5 unter dem Pfad, die auch entweder zu Compat5.x oder Compat6.x gehört. Liegt aber daran, dass ich das System immer wieder mit make buildworld aktuell gehalten habe und eine Abwärtskompatiblität gewährleisten wollte. Vieleicht ists ja auch bei lockdoc so. Müsste es mal runterhauen, bin aber nie dazu gekommen.
Zum Vergrößern anklicken....

Also ich habe mein System auch immer fleissig geupdated und bin jetzt bei der 9-Current.
Meine png Version ist png-1.4.5

Code: 
user> ls /usr/local/lib/compat/pkg/ | grep png
bleibt leer

Sachmal, kann ich denn den ganzen compat Dr#$# deinstallieren?
 
Wenn du alles neu baust, kannst du das compat Paket deinstallieren. Es sei denn du hast BLOBs die eine andere FreeBSD Version brauchen.

Ansonsten, wenn du ein library Problem hast, verwende pkg_libchk.
 
Also Deinstallieren kannst du es natürlich, aber wie Kamikaze schon sagt, vorher prüfen, nicht das ein Blob gerade darauf besteht. Weis nicht, in wiefern sich der Pfad auf dem 9 Current ändert. Aber wenn es leer ist und du vorerst das libpng.so.5 benötigst, solltest du das Compat reinstallieren bzw installieren. Glaub da kommst du sicher nicht drumm herum. Wenn du nicht vorhast, deine kompletten Ports neu zu installieren.
 
ich weiß nicht, ob das nun ausreichend deutlich wurde: der Neubau, bzw, die Antwort darauf, was neuer ist, bezieht sich auf deinen lokalen PortsTree. Nur dann, wenn dieser aktuell ist, ist das identisch mit den derzeit gültigen Versionen der Ports und das hat nichts mit der Version deines FreeBSD zu tun (ob du CURRENT nimmst oder 7.4).

Anders gesagt, wenn du nicht vorher den PortsTree aktualisierst, baust du immer wieder die gleichen Versionen, besonders mit -f.

Einen Abbruch beim Bauen halte ich persönlich für weniger schlimm.
Es kann "schlimme" Folgen haben, doch auch nicht schlimmer, als man sie ohnehin gelegentlich mal erlebt. Das bedeutet, die pkgdb könnte leiden und müsste evtl neu aufgesetzt werden. Außerdem können die gerade gebauten Ports in ihren Work-Directories unsauber sein, weshalb vor einem Neustart vielleicht besser erst mal gecleaned werden sollte (PORTSCLEAN(1)).

Wiederum eine persönliche Meinung: der -k ist mir immer willkommen. Es macht gar nichts, wenn ein Port nicht direkt durchgebaut werden kann. Du bekommst am Ende einen report und eine kurze Ursache und auch die Ports, die dadurch ausgelassen werden mussten, weil ein bestimmter Port nicht gelang. Es ist bei mir oft so, dass ich längere Zeit keine Updates mache und dann würde ich Tage und mitunter Wochen brauchen (wobei dann natürlich wieder jede Menge Neuerungen verfügbar sind), weil ich nicht jedes Problem einzeln anpacken kann; ich sitze nicht dauernd vor der Kiste. Mit -k kann ich aber den Großteil abarbeiten lassen und mich dann der wenigen Prozent fehlgeschlagener Ports annehmen.
Das ist für mich auch ein Grund, nicht zu portmaster zu wechseln und weiter portupgrade zu nutzen.
portmaster lasse ich nur im Probelauf (-n) vorab (vor einem portupgrade -a) laufen, um die Optionen (make config) für neue Ports möglichst schon vorab setzen zu können. Ansonsten bleibt ja portupgrade an solchen Stellen stehen und wartet auf eine Eingabe, was wiederum für mich ziemlich schlecht ist.

So richtig intelligent sind beide Werkzeuge nicht. Die eigentliche Intelligenz steckt wohl eher im Aufbau des Ports-Systems, wo die jeweiligen Abhängigkeiten beschrieben sind. Portmaster und portupgrade lesen nur die Informationen aus und stellen Listen zusammen, die dann abgearbeitet werden.

PKG_GLOB(1) benutzt die gleiche Syntax wie portupgrade (das ist nun wirklich doof beschrieben, was ich meine ist: )
pkg_glob:
Code: 
     -r
     --recursive         List all those packages depending on the given pack-
                         ages as well.

     -R
     --upward-recursive  List all those packages required by the given pack-
                         ages as well.
portupgrade:
Code: 
     -r
     --recursive            Act on all those packages depending on the given
                            packages as well.

     -R
     --upward-recursive     Act on all those packages required by the given
                            packages as well. (When specified with -F, fetch
                            recursively, including the brand new, uninstalled
                            ports that an upgraded port requires)
portmaster:
Code: 
     [-R] -r name/glob of port directory in /var/db/pkg
         rebuild the specified port, and all ports that depend on it.  The
         list of dependent ports is built according to origin (i.e.,
         category/portname) not by the version number of the installed port.
         So if you do portmaster -r fooport-1.23 and it is necessary to
         restart using -R but the newly installed port is now fooport-1.24 you
         can do portmaster -R -r fooport-1.24 and it should pick up where you
         left off.

     -R  used with the -r or -f options to skip ports updated on a previous
         run.  When used with -r it will also prevent the rebuild of the par-
         ent port if it, and all of its dependencies are up to date.
und außer Konkurrenz, pkg_upgrade:
Code: 
     -r --recursive
             Also process packages the given packages depend on. Note that
             this is the meaning of -r used by pkg_info(1), not the meaning
             used by most popular port maintainance tools.

             The -r flag can be specified a second time if the -R flag is also
             given. It causes the dependencies of depending packages listed
             for updating to be processed as well.

     -R --upward-recursive
             Also process packages depending on the given packages.

             The -R flag can also be specified for a second time to process
             packages depending on dependencies listed for updating as well.
             Because missing dependency checks are always performed, this does
             not require the -r flag.
pkg_glob liefert unter anderem leicht entsprechende Listen mit den Abhängigkeiten eines Ports (vermutlich ähnlich, wie du sie mit dem weiter oben zitierten portupgrade -...n bekommst).
 
Hi,
meine Frage nach der Version der libpng.so .5 bezog sich nicht auf die installierte Version (png-1.4.5 gibt libpng.so .6), sondern danach, warum ein Port die veraltete Version haben will.
Daher die Vermutung, daß er Portstree evtl. nicht aktuell ist.
Das Basisystem zu tracken ist wieder eine andere Baustelle ;)

Das beste ist sicher so wie du es machst, alle abhängigen Ports etc. neu zu bauen.
Es gibt auch in /usr/ports/UPDATING einen entsprechenden Hinweis, allerdings zu von vor über einem Jahr.
Wenn man da dann lange genung draufkuckt, hat das auch halluzinogen-hypnotische Effekte. Manch einer bezahlt für sowas viel Geld.:ugly:

Ein kleiner Hack, aber nicht dauerhaft und ohne Garantie, ist in der /etc/libmap.conf
wie folgt die libraries zu mappen.
Code: 
libpng.so.5             libpng.so.6
Aber wie gesagt, es geht nix über kompilierende Computer.
hth
 
metro schrieb:
Ein kleiner Hack, aber nicht dauerhaft und ohne Garantie, ist in der /etc/libmap.conf
wie folgt die libraries zu mappen.
Code: 
libpng.so.5             libpng.so.6
Aber wie gesagt, es geht nix über kompilierende Computer.
hth
Zum Vergrößern anklicken....

Kann er auch machen, wenn es nur die einzige Abhängigkeit ist. Aber meist ist dem nicht so, dann editiert er sich nur dumm und dusselig. Sauber ist es Compat in den Versionen zu vorerst zu installieren. Nach eniger Zeit sind die Ports dann sicher mit der neuen Version gebaut und das Compat kann deinstalliert werden.

Er kann auch Radikalkur machen.

Code: 
umount /compat/linux/proc
rm -rf /usr/local /var/db/pkg /var/db/ports /compat/linux

Danach kann er alle Ports komplett neu bauen. Aber bei 1000 Ports kanns mindestens eine Woche dauern bis alles so läuft wie es soll. :ugly:
 
bluebyte schrieb:
Kann er auch machen, wenn es nur die einzige Abhängigkeit ist. Aber meist ist dem nicht so, dann editiert er sich nur dumm und dusselig. Sauber ist es Compat in den Versionen zu vorerst zu installieren. Nach eniger Zeit sind die Ports dann sicher mit der neuen Version gebaut und das Compat kann deinstalliert werden.

Er kann auch Radikalkur machen.

Code: 
umount /compat/linux/proc
rm -rf /usr/local /var/db/pkg /var/db/ports /compat/linux

Danach kann er alle Ports komplett neu bauen. Aber bei 1000 Ports kanns mindestens eine Woche dauern bis alles so läuft wie es soll. :ugly:
Zum Vergrößern anklicken....

Der Sinn des Ganzen bleibt mir irgendwie verborgen. Er kann natürlich auch nen Kanister Benzin im Zimmer verschütten und anzünden.:confused: Oder eine handelsübliche Axt mit entsprechender Dynamik am Rechner eingesetzt soll ebenfalls Wunder wirken.
 
Der Sinn des ganzen ist, wenn der eine oder andere Port auf eine alte Version besteht, kann er die Abwärtskompatiblität durch die Ports nutzen. Da braucht er nicht lange zu editieren. Die besagten Compats installieren sich innerhalb weniger Sekunden und sind nicht so groß. Wenn dann diese Ports irgendwann diese Compat nicht mehr benötigt, ist sie genau so schnell deinstalliert. Denn die meisten Ports verwenden eh die aktuellen Abhängigkeiten, dann kann es durchaus sein, dass der Port, der momentan dieses Problem bei ihm verursacht, beim nächsten Portupgrade diese Compat nicht mehr verwendet.

Die Radikalkur bezieht sich darauf, falls er Angst hat, sein System mit dem Compat gegen die Wand zu fahren, kann er es auch gern auf die Weise probieren, so erspart er sich eine Neuinstallation und Konfiguration vom ganzen System. Brauch dann nur die 1000 Ports neu zu bauen. Die holen sich dann schon was sie brauchen.
 
Er kann auch mit pkg_libchk schauen, was tatsächlich neu gebaut werden sollte. Das sind bei weitem nicht alle Ports.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben