Binärupdates von Paketen

Das kannst du ja gerne irgendwem mitteilen.

Ich glaube Pakete existieren unter FreeBSD nur für die Erstinstallationen und um zu testen ob die Ports funktionieren.

Die Idee die Pakete auf den Servern für etwas Anderes zu verwenden ist FreeBSD Nutzern so fremd, dass ihnen der Gedanke bizarr und sinnlos vorkommt.
 
Mist, leider habe ich keine script ausgabe oder dergleichen mitgeschnitten. tut mir leid. Hätte ich wirklich dran denken können.:gpaul:

boost war jedenfalls vorher installiert, das ist richtig.
Um zu testen ob es an pkg_upgrade oder pkg_add liegt, habe ich es mit "pkg_add -r boost-python" versucht, was die gleiche Fehlerausgabe zur folge hatte, es konnte nicht installiert werden.
Auf jedenfall hat pkg_upgrade abgebrochen an dieser stelle.(ohne weitergehende Fehlermeldung ausser der die auch pkg_add geliefert hat)

Ansonsten gab es noch Schwierigkeiten mit "p5-XML-SAX-Expat-0.40" welches nicht installieren wollte. (Irgendwelcher Namespace conflict).Das habe ich dann per portmaster gebaut.
gezogen habe ich die packete vom ftp2.de.freebsd.org.
Benutzt habe ich es um mein Desktop zu aktualisieren.

------------
Die User müssen sich auch erst mal daran gewöhnen, das es eine gute und funktionierende Möglichkeit gibt bequem und schnell packete upzudaten.
Ich würde am Anfang nicht zu viel erwarten.
Nützlich ist es allemal. Nicht nur für mich. Ich brauch nicht immer die brandaktuellen Sachen.
Natürlich wäre es in meinen Augen wünschenswert aktuelle packete zu bekommen, vor allem bei sicherheitskritischen sachen,(Browser, Webserver...etc)

Ich werde jedenfalls weiter mit pkg_upgrade arbeiten, weil ich keine Lust habe auf meinem schleptop immer irgendwelche KDE kompielerorgien zu starten.
Ich finde es jedenfalls super das du so ein ehrgeiziges Projekt gestartet hast.

Nächstes mal werde ich auch loggen.

gruß
 
rolle schrieb:
Mist, leider habe ich keine script ausgabe oder dergleichen mitgeschnitten. tut mir leid. Hätte ich wirklich dran denken können.:gpaul:
Zum Vergrößern anklicken....
/var/log/pkg_upgrade.log ?

rolle schrieb:
boost war jedenfalls vorher installiert, das ist richtig.
Um zu testen ob es an pkg_upgrade oder pkg_add liegt, habe ich es mit "pkg_add -r boost-python" versucht, was die gleiche Fehlerausgabe zur folge hatte, es konnte nicht installiert werden.
Auf jedenfall hat pkg_upgrade abgebrochen an dieser stelle.(ohne weitergehende Fehlermeldung ausser der die auch pkg_add geliefert hat)
Zum Vergrößern anklicken....
Das sollte auf gar keinen Fall passieren.

Code: 
# Try to install the new package.
printStatus "Install <$targetPkgname>."
if ! env PKG_PATH="$PACKAGES/All" pkg_add -f "$targetPkgname"; then
	# Installation went wrong, roll back!
	printStatus "Roll back changes for <$targetPkgname>."
	for file in $(find "$PKG_DBDIR" -name "*.$name"); {
		mv -f "$file" "${file%.$name}"
	}
	count=-1
	for package in $removePackages; {
		# Restore package.
		env PKG_PATH="$packagebackup" pkg_add -f "$package"
		# Recover +REQUIRED_BY file.
		count=$(($count + 1))
		eval "echo \"\$requiredBy$count\"" > "$PKG_DBDIR/$package/+REQUIRED_BY"
		# Remove the backup if set.
		test -n "$pNoBackup" && rm "$packagebackup/$package.tbz"
	}
	log $ERR_INSTALL "$task"
	error $ERR_INSTALL "The installation of <$targetPkgname> failed."
fi

Wie man sieht sollten Fehler zumindest zu einem Roll-Back und einer Fehlermeldung führen.

rolle schrieb:
Ansonsten gab es noch Schwierigkeiten mit "p5-XML-SAX-Expat-0.40" welches nicht installieren wollte. (Irgendwelcher Namespace conflict).Das habe ich dann per portmaster gebaut.
gezogen habe ich die packete vom ftp2.de.freebsd.org.
Benutzt habe ich es um mein Desktop zu aktualisieren.
Zum Vergrößern anklicken....
Das wird ja immer bizarrer. Eigentlich ist die einzige anzunehmende Möglichkeit für pkg_add -f zu scheitern eine volle Partition.

rolle schrieb:
Die User müssen sich auch erst mal daran gewöhnen, das es eine gute und funktionierende Möglichkeit gibt bequem und schnell packete upzudaten.
Ich würde am Anfang nicht zu viel erwarten.
Zum Vergrößern anklicken....
Zumindest bei dir hat es ja nicht gut funktioniert. Diese Art Probleme hatte ich beim Testen nie.

rolle schrieb:
Nützlich ist es allemal. Nicht nur für mich. Ich brauch nicht immer die brandaktuellen Sachen.
Natürlich wäre es in meinen Augen wünschenswert aktuelle packete zu bekommen, vor allem bei sicherheitskritischen sachen,(Browser, Webserver...etc)

Ich werde jedenfalls weiter mit pkg_upgrade arbeiten, weil ich keine Lust habe auf meinem schleptop immer irgendwelche KDE kompielerorgien zu starten.
Ich finde es jedenfalls super das du so ein ehrgeiziges Projekt gestartet hast.

Nächstes mal werde ich auch loggen.

gruß
Zum Vergrößern anklicken....
Log ist per Default an. Da ist zwar nicht alles drin, aber es wäre doch zumindest ein Hinweis.
 
Hilft das den weiter?

Code: 
1241656761 - Do  7 Mai 2009 00:39:21 UTC - DONE: Conflict <boost-python-1.37.0> (devel/boost-python) favour packag
e(s) <boost-1.34.1> (devel/boost)
1241656828 - Do  7 Mai 2009 00:40:28 UTC - DONE: Conflict <boost-python-1.37.0> (devel/boost-python) favour package(s) <boost-1.34.1> (devel/boost)
1241656886 - Do  7 Mai 2009 00:41:26 UTC - DONE: Conflict <boost-python-1.37.0> (devel/boost-python) remove package(s) <boost-1.34.1> (devel/boost)
1241657069 - Do  7 Mai 2009 00:44:29 UTC - DONE: Update <boost-python-1.34.1> to <boost-python-1.37.0> (devel/boost-python)
1241657145 - Do  7 Mai 2009 00:45:45 UTC - DONE: Conflict <tidy-lib-090315.c> (www/tidy-lib) favour package(s) <tidy-20000804_2> (www/tidy)
1241657177 - Do  7 Mai 2009 00:46:17 UTC - DONE: Conflict <tidy-lib-090315.c> (www/tidy-lib) remove package(s) <tidy-20000804_2> (www/tidy)
1241657183 - Do  7 Mai 2009 00:46:23 UTC - DONE: Update <tidy-lib-080621.c> to <tidy-lib-090315.c> (www/tidy-lib)
1241657231 - Do  7 Mai 2009 00:47:11 UTC - DONE: Update <p5-XML-SAX-0.96> to <p5-XML-SAX-0.96> (textproc/p5-XML-SAX)
1241657270 - Do  7 Mai 2009 00:47:50 UTC - ERROR(8): Install <p5-XML-SAX-Expat-0.40> (textproc/p5-XML-SAX-Expat)

Wie kann ich nächstes mal noch mehr loggen ? was dir im falle eines fehlers helfen könnte ?

-----edit----
ERR_INSTALL 8
There was an error while installing a package. The most likely
cause is a lack of disk space.
--------
das ist nicht der fall!
 
Zuletzt bearbeitet:
Interessant ist erst mal, dass es nach dem boost-Konflikt nicht weiterging und es trotzdem keine Fehlermeldung gibt. War er da fertig?

Was p5-XML-SAX-Expat-0.40 betrifft, ich würde liebend gern' die komplette Ausgabe sehen.

Wenn du noch mehr loggen willst, bleiben dir nur noch stdout und stderr in eine Datei umzuleiten.
 
Das ist natürlich nicht ungewöhnlich. Da bleibt einem eigentlich nur mit pkg_upgrade -an nachzuschauen.

Alternativ, was schneller geht, weil keine fehlenden Abhängigkeiten geprüft werden:

Code: 
# pkg_version -Iol\< /var/db/uma/FTPINDEX
 
Ich habe noch einen Fehler gefunden unter CURRENT:
Code: 
fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/INDEX: File unavailable (e.g., file not found, no access)

Hier wird nach packages-8-stable gesucht, es muss aber packages-8-current heißen.

Ein manuelles Setzen von PACKAGESITE klappt auch nicht:
Code: 
lars@pts/4 # setenv PACKAGESITE ftp://ftp7.de.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/
lars@pts/4 # pkg_upgrade -an
fetch: ftp://ftp7.de.freebsd.org/pub/FreeBSD/ports/i386/INDEX: File unavailable (e.g., file not found, no access)
 
Kannst du mal in /usr/local/sbin/uma nach "stable | current)" suchen und das mit "stable|current)" ersetzen?

Dann mit uma env nachprüfen ob das funktioniert hat.
 
Das hat leider keine Abhilfe gebracht:
Code: 
lars@pts/6 > uma env
ARCH='i386'
FTP_TIMEOUT='60'
PACKAGEROOT='ftp://ftp7.de.freebsd.org'
PACKAGESITE='ftp://ftp7.de.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/Latest'
PKG_INDEX='/var/db/uma/FTPINDEX'
 
OK, ich habe das Problem gefunden. Bis zum Update kannst du ja BRANCH in der uma.conf setzen.
 
So mein Erfahrungsbereicht:

Ich habe nicht das komplette System upgegraded sondern erst kde3 entfernt, da ich danach kde4 haben wollte.

Direkt nach dem Starten hat er acuh angefangen boost herunterzuladen statt boost-python, weswegen ich abgebrochen habe und mit -C neugestartet. Am Ende wurde dann trotzdem boost statt boost-python installiert. Mit pkg_upgrade -o konnte ich das fixen.
Insgesamt hat es eine Weile gedauert, da der Mirror ziemlich lahm war und ich kein Ersatz angegeben hatte. Mehrere parallele Downloads hat er nicht gemacht, soweit ich das beurteilen kann. Braucht er dafür auch Mirror?

Insgesamt war die Arbeit des Tools sehr zufriedenstellend:
Code: 
fbsdmain# pkg_version -vI /var/db/uma/FTPINDEX | grep \<
fbsdmain#
:)

Den log habe ich mal angehangen!

Ich denke, dass es besonders auf Servern seine Stärke auspielen wird. Da gibt es weniger Pakete insgesamt und da will man erst Recht nicht seine CPU-Cycles auf Kompilieren verschwenden.
 

Anhänge

soul_rebel schrieb:
So mein Erfahrungsbereicht:

Ich habe nicht das komplette System upgegraded sondern erst kde3 entfernt, da ich danach kde4 haben wollte.

Direkt nach dem Starten hat er acuh angefangen boost herunterzuladen statt boost-python, weswegen ich abgebrochen habe und mit -C neugestartet. Am Ende wurde dann trotzdem boost statt boost-python installiert.
Zum Vergrößern anklicken....
Ja, eben weil du -C verwendet hast. Sonst wäre das richtig gelaufen. Das Programm kann ja nicht im voraus wissen, dass es einen Konflikt gibt. Die Information ist nur im Package zu finden, deshalb muss das natürlich auch zuerst heruntergeladen werden.
soul_rebel schrieb:
Mit pkg_upgrade -o konnte ich das fixen.
Insgesamt hat es eine Weile gedauert, da der Mirror ziemlich lahm war und ich kein Ersatz angegeben hatte. Mehrere parallele Downloads hat er nicht gemacht, soweit ich das beurteilen kann. Braucht er dafür auch Mirror?
Zum Vergrößern anklicken....
Wenn du nichts einstellst nimmt er die Primary-Mirrors. Er hat garantiert parallel heruntergeladen, aber die Mirrors sind eben ausnahmslos hoffnungslos veraltet. Mit uma env kannst du prüfen welche mirrors verwendet wurden.

Mit tail -f /tmp/pkg_upgrade.messages.queue kannst du die Kommunikation mit dem Download Manager nachvollziehen, nachdem der gestartet wurde.

Der Download Manager versucht es 2 mal von den Mirrors. Wenn der zweite Versuch scheitert meldet er sofort einen erfolgreichen Download. Dann wird das ganze bei der Überprüfung der Pakete erkannt und ein Download vom Primary Server im Vordergrund gestartet.
soul_rebel schrieb:
Insgesamt war die Arbeit des Tools sehr zufriedenstellend:
Code: 
fbsdmain# pkg_version -vI /var/db/uma/FTPINDEX | grep \<
fbsdmain#
:)

Den log habe ich mal angehangen!

Ich denke, dass es besonders auf Servern seine Stärke auspielen wird. Da gibt es weniger Pakete insgesamt und da will man erst Recht nicht seine CPU-Cycles auf Kompilieren verschwenden.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Endlich! Es gibt frische Binärpakete für amd64!

Von 31 zu aktualisierenden Paketen waren auf den deutschen Mirrors 8.
 
Zuletzt bearbeitet:
Ich wollte nochmal betonen wie praktisch dieses Tool ist! Ich upgrade jetzt öfter mall "einfach so" ohne konkreten Anlass. Das war früher immer zu anstrengend, wegen Interaktion und Build-Phasen.

Ich vermisse gerade nur die Möglichkeit Pakete auf "HOLD" zu setzen, also festzulegen, dass z.B. mplayer nie-nie als Paket installiert werden soll.
 
Könnte ich einbauen. Ich bin noch nicht auf die Idee gekommen. Aber ich bin schon fleißig am weiterentwickeln.

Deswegen wird auch der fetch-Wrapper noch zrückgestellt. Das Blacklisten ist eigentlich ziemlich simpel, das kann ich auch noch ins nächste Release nehmen.

Mit ps kommt man übrigens an den aktuellen download Status, ich schaue mir das gerade an, vielleicht ist ein Wrapper da überflüssig.

--- edit ---
Zumindest dachte ich das, jetzt finde ich es nicht mehr.
 
Zuletzt bearbeitet:
soul_rebel schrieb:
Ich vermisse gerade nur die Möglichkeit Pakete auf "HOLD" zu setzen, also festzulegen, dass z.B. mplayer nie-nie als Paket installiert werden soll.
Zum Vergrößern anklicken....
Wie hättest du die Blacklist denn gerne? Paketnamen oder category/port? Oder beides?

In der Konfigurationsdatei oder als separate Datei? Ich will das morgen implementieren.
 
Kamikaze schrieb:
Wie hättest du die Blacklist denn gerne? Paketnamen oder category/port? Oder beides?

In der Konfigurationsdatei oder als separate Datei? Ich will das morgen implementieren.
Zum Vergrößern anklicken....

Hm, eher mit origin, aber mir eigentlich egal. Vielleicht könnte man die Einstellungen aber mit portupgrade und /oder portmaster teilen, dass würde die user sicherlich freuen!
 
Ich kann mir nicht vorstellen wie das funktionieren soll.

Soll dann portmaster ports nicht bauen, die pkg_upgrade als Paket nicht installiert?
 
Kamikaze schrieb:
Ich kann mir nicht vorstellen wie das funktionieren soll.

Soll dann portmaster ports nicht bauen, die pkg_upgrade als Paket nicht installiert?
Zum Vergrößern anklicken....

Ja, so ungefähr. Bestimme Ports sollen halt nie automatisch aktualisiert werden (manche vielleicht auch nur nicht binär). Portupgrade und Konsorten nutzen pkgtools.conf und die HOLD_PKS-Variable...

Aber vielleicht kannst du ja die Entwickler anfragen ob ihr euch auf eine gemeinsame externe Datei und Format einigen könnt.
 
Ich würde eigentlich prinzipiell davon abraten Pakete mit pkg_delete, pkg_add oder make deinstall reinstall zu aktualisieren. Erst bei der Arbeit an pkg_upgrade ist mir aufgegangen wie sehr man sich damit die Abhängigkeiten zerstört. Wobei pkg_upgrade zum Glück vollkommen Immun dagegen ist, weil alle Informationen zu Abhängigkeiten aus dem INDEX kommen.

pkg_upgrade wird in der nächsten Version auch das gezielte installieren eines bestimmten Pakets, das lokal vorliegt, unterstützen (statt nur Versionen aus dem Index zu installieren). Hauptsächlich damit man beim Zurückspielen von Backup-Paketen nicht pkg_delete und pkg_add bemühen muss und man sich damit die Abhängigkeiten zerschießt.

Ich denke eigentlich, dass man bestimmte Ports als Pakete und andere bauen will, also sollten die Tools auch eigene Blacklists haben. Man kann ja in der Konfiguration so etwas wie

BLACKLIST="$HOLD_PKS"

definieren. Wenn HOLD_PKS im Environment ist. So wie ich die Manual-Page verstehe wird das nur in der pkgtools.conf gesetzt und die ist ein ruby-Skript, also denkbar ungeeignet für so etwas.
 
Ja so esseintiell war das jetzt auch nicht, aber
pkgtools.con schrieb:
# To completely hide the existence of a package, put a dummy file
# named "+IGNOREME" in the package directory.
Zum Vergrößern anklicken....
müsste doch recht einfach zu supporten sein!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben