Wie macht man ein Update/Upgrade von installierten Pkg's in NetBSD (suber)???

Q

quarzsnoopy

[Free|Net]BSD - User
Hallo Leute,
bin seit 5 Jahren begeisterter FreeBSD-User, da seinerzeit NetBSD (Version 1.5) noch nicht alles konnte was ich wollte (brauchte). Jetzt mit der Version 2 sieht die Sache schon ganz anders aus...

Kurz gesagt ich will mich jetzt intensiver in NetBSD reinarbeiten um dann komplett von FreeBSD auf NetBSD umzusteigen (ich finde NetBSD ist das aufgeräumteste, ordentlichste und durchdachteste Unix, das ich je ausprobiert habe!) zu können.
Mein erstes grosses Problem ist, wie aktuallisiere ich alle installierten, oder nur einzelne Packete in NetBSD?
In FreeBSD mache ich das mit:
alle, rekursiv: portupgrade -RNOka
eins, samt Ahängigkeiten: portupgrade -RNO [Packetname]

Wie geht das mit NetBSD einfach und sauber?


Wir bekomme ich von einem installierten Packet dan Pfad im pkgsrc-Baum raus?
Bei FreeBSD geht das mit "pkg_info -qo [Packetname]".


Es wäre sehr freundlich, wenn Ihr mir dabei helfen könntet. :)
 
Standardmaessig werden NetBSD Packages unter /usr/pkg/ abgelegt.

Zum Thema saubere Updates: Wenn du Vorkompilierte Packages verwendest: pkg_add -u [paket]
In der Pkgsrc: make update (braucht aber ewig)

angabe ohne gewaehr
 
make update

SierraX schrieb:
Standardmaessig werden NetBSD Packages unter /usr/pkg/ abgelegt.

Zum Thema saubere Updates: Wenn du Vorkompilierte Packages verwendest: pkg_add -u [paket]
In der Pkgsrc: make update (braucht aber ewig)

angabe ohne gewaehr
Zum Vergrößern anklicken....

Ich nehme lieber die Pkgsrc, hab ich mich schon seit FreeBSD dran gewöhnt, denn hier kann man sich die Pkg's mit Parametern kompilieren. Bei den Binärpackages muss man es nehmen wie's gerade da ist.

Ja, das mit dem "make update" hatte ich auch schon gelesen, da stellt sich mir aber die Frage nach der praktischen Durchführung:
Wenn ich alle Packages updaten will, (unter FreeBSD habe ich fast 600 installiert) und das sind ja meist nicht so wenige, sollte man das schon wenigstens scripten können. Um das per Script zu machen muss ich aber von einem installierten Packages das "origin" (z.B. mail/thunderbird) rausbekommen. Unter FreeBSD macht man das mit "pkg_info -o [Packages]", unter NetBSD gibt es aber den Parameter "-o" nicht...?!?!?!?!
Dann würde mein Script beispielsweise so aussehen:

pkg_info | awk '{print $1}' | while raed AAA
do
cd /usr/pkgsrc/`pkp_info -qo $AAA` && make update && make clean
done

Nur leider gibt es den Parameter " -o " beim pkg_info von NetBSD nicht.... :confused:
 
Pakages - Management ???

Ich habe auf den NetBSD-Seiten keine Anleitung gefunden, in der beschrieben ist wie man ein NetBSD-System ordentlich aktuell hält.
Wie pflegt man ein NetBSD über eine lange Zeit (Jahrzehnte)?
Gibt es hier keine anständigen Tools? Das ist dann in meinen Augen ein KO-Kriterium! Ich habe keine Lust immer alles neu zu installieren.
 
kaishakunin schrieb:
http://wiki.bsdforen.de/index.php/NetBSD_-_stable_update

http://www.netbsd.org/Documentation/updating.html
http://www.netbsd.org/Documentation/current/
Zum Vergrößern anklicken....


Danke für Deine Mühe!
Aber das NetBSD-System an sich habe ich im Griff, ich habe nur keine Lösung für das automatische updaten/upgraden der Packages!

Einzelne Packages kann man mit "make update" updaten, aber wie sieht das mit ALLEN Packages am Stück aus? Wie kann ich ein "make update" rekursiv machen?
 
Geht das so?

Ich hab da was gefunden:
http://www.bsdforen.de/archive/index.php/t-8977.html

1. pkgsrc updaten
2. cd /usr/pkgsrc/pkgtools/pkg_install
3. make bin-install clean clean-depends
4. pkg_add -fuuv kde-3.3.2nb1
5. mit "pkg_info|grep -i kde" gucken, welche KDE Pakete noch nicht
upgedatet sind, und sie jeweils mit "pkg_add -fuuv ..."
nachinstallieren - fertig!


Ich habs noch nicht ausprobiert, aber ich glaube das ist doch die Beschreibung für ein Binär-Update.
Wie macht man das ganze nun mit "PKGSRC"?

Das entscheidende was mir fehlt um ein entsprechendes Script schreiben zu können ist
wie bekomme ich das "origin"-Verzeichnis (z.B. "meta-pkgs/gnome") raus, wenn ich nur den Package-Namen habe?
 
Zuletzt bearbeitet:
Ich denke, ich habs...

Hier will ich mal veröffentlichen, was ich als NetBSD-Alternative zu dem
FreeBSD-Befehl: "portupgrade -RNOka"
gefunden habe...

Ich habe den Befehl "make update" noch nicht ausprobiert, aber ich gehe mal davon aus, das er tut was ich von ihm erwarte.

Also, die einzige Stelle in NetBSD, an der ich das origin eines jeden installierten Package finden konnte ist in der Datei "/usr/pkgsrc/INDEX".

So, mit diesem Wissen kann man sich ein Script schreiben, mit dessen Hilfe man einfach und ohne viel Handarbeit alle Packages im System updaten kann.
Hier ist meine (erste) Version dieses Scripts:




#!/bin/sh

### fuer jedes einzelne Package
pkg_info | awk '{print $1}' | while read PAKETNAME
do
### findet den Pfad im pkgsrc des Package (origin)
ORIGIN=`cat /usr/pkgsrc/INDEX | grep ^$PAKETNAME | awk -F '|' '{print $2}'`
#
### nur fuer Testzwecke
#echo "cd /usr/pkgsrc/$ORIGIN && (make clean-depends ; make update ; make clean-depends)"
#
### Package updaten
cd /usr/pkgsrc/$ORIGIN && (make clean-depends ; make update ; make clean-depends)
done
 
quarzsnoopy schrieb:
Ich habe den Befehl "make update" noch nicht ausprobiert, aber ich gehe mal davon aus, das er tut was ich von ihm erwarte.
Zum Vergrößern anklicken....

Obacht! "make update" kann böse ins Auge gehen.
Wenn du ein Paket mit make update aktualisieren willst, werden *alle* Dependencies entfernt und dann neu gebaut.

Wenn die Deps weg sind, werden natürlich auch deren Deps entfernt, so das man mit einem Befehl fast alle Pakete loswerden kann.

Ich habe mal mplayer mit make update aktualisieren wollen, was dazu führte das GTK weg war - und mit GTK auch Gimp, XFCE, VIM-gtk usw. usf.

Da das neue GTK aber nicht bauen wollte, saß ich nun auf dem Trockenen und hatte einige wichtige Programme weniger. Daher empfehle ich dringendst ein chroot-Environment zu benutzen und darin erst die neuen Versionen zu kompilieren. Wie das geht steht in meiner Anleitung im WIki.

PS: man stelle sich nur mal vor Perl wird entfernt, dann gehen auch Apache, PostgreSQL und ca 80 aller anderen Pakete ;-)
 
Danke!!!

Danke kaishakunin für den Hinweis!
Sowas ist ja im Prinzip richtig fahrlässig, denn die Ports haben ja immer mal ne macke. Das ist ja nicht zu vermeiden...

Bei FreeBSD wird das Package erst kompiliert und dann nur diese Abhängigkeit gelöst und nach der installation neu gebunden oder das alte wieder hergestellt.

Dann ist wohl "pkgtools/pkg_chk", was ookami empfohlen hat, genau das was ich suche. Danke ookami!

Ich habe zwar ein aktuelles NetBSD gerade installiert, werde das aber gleich ausprobieren, wenn sich die Gelegenheit bietet.

Bis dahin habe ich noch eine Frage:
Kann ich mit "pkg_chk" auch Packages installieren. Wobei dann Packages, die benötigt werden (Abhängigkeiten) und in einer alten Version schon installiert sind, auch upgedatet werden? Also Installation mit rekursivem Update. (so funktioniert das bei FreeBSD z.B.)

Der FreeBSD-Befehl funktioniert so:
portupgrade -RNO [Packetname]

-R rekursives Update
-N es dürfen auch neue Packages hinzugefühgt werden
-O wenn ein Distfile kaputt ist, neu saugen

-k weitermachen, auch wenn die installation oder das Update eines Package fehl schlägt
-a alle installierten Packages upgraden


Kann "pkg_chk" das auch?
 
pkg_chk kann zwar updates machen, aber eben nur mit "make update", was idR nicht viel bringt.

Es gab schon des öfteren Diskussionen darüber auf den Mailinglisten, es kann auch sein das jemand daran arbeitet die Updates effizienter zu machen.


Wenn es dich genauer interessiert, durchsuch mal tech-pkg@netbsd
 
quarzsnoopy schrieb:
Ich hab da was gefunden:
[...]
Ich habs noch nicht ausprobiert, aber ich glaube das ist doch die Beschreibung für ein Binär-Update.Wie macht man das ganze nun mit "PKGSRC"?
Zum Vergrößern anklicken....

In dem Fall handelte es sich um ein Update von KDE. Ein automatisches Update aller installierten Pakete is nicht möglich - es sei denn Du bastelst selber ein entsprechendes Script.

Gavan Fantom hat ein experimentelles Script für PKGSRC erstellt. Es arbeitet mit
pkg_chk, pkg_comp (also chroot) und lintpkgsrc::
http://www.coolfactor.org/~gavan/update/

Der Nachteil dabei ist, dass die Updates nur dann durchgeführt werden, wenn alle Pakete erfolgreich gebaut wurden. Wenn nicht, muss man die erfolgreich gebauten Pakete von hand (also jeweils mit pkg_add...) installieren. Es fehlt also ein Script, das im Anschluss zumindest alle fertig gebauten Pakete updatet.


Zu Deiner anderen Frage:

# pkgfind pkgfind
pkgtools/pkgfind: Find packages by package name in pkgsrc


viel Erfolg!
 
quarzsnoopy schrieb:
Sowas ist ja im Prinzip richtig fahrlässig, denn die Ports haben ja immer mal ne macke. Das ist ja nicht zu vermeiden...
Zum Vergrößern anklicken....

Genau deswegen redet man ja von der "make update hell"
Aber zum Glück hat man dann immer noch sein Backup...

Trotzdem gibt es dann und wann Fälle, in denen man "make update" braucht
z.B. für pkgtools/pkg_install

Zur Zeit beste Praxis ist aber immer noch pkg_comp, also das gefahrlose neubauen in einer Sandbox:
http://www.bsdfreak.org/modules/news/article.php?storyid=1


quarzsnoopy schrieb:
Kann ich mit "pkg_chk" auch Packages installieren. Wobei dann Packages, die benötigt werden (Abhängigkeiten) und in einer alten Version schon installiert sind, auch upgedatet werden?
Zum Vergrößern anklicken....

Ja, pkg_chk kann zum Updaten auch binaries nehmen. Allerdings lädt es sich die nicht selbständig runter. Wenn die alten Abhängigkeiten installiert wurden, werden sie natürlich wie alle anderen veralteten Pakete auch upgedatet.


Ciao
 
mawei schrieb:
Der Nachteil dabei ist, dass die Updates nur dann durchgeführt werden, wenn alle Pakete erfolgreich gebaut wurden. Wenn nicht, muss man die erfolgreich gebauten Pakete von hand (also jeweils mit pkg_add...) installieren. Es fehlt also ein Script, das im Anschluss zumindest alle fertig gebauten Pakete updatet.
Zum Vergrößern anklicken....

Naja, ich weiß nicht ob es immer 100% glatt geht wenn man die erfolgreich gebauten Pakete einspielt. Könnte wieder zu Abhängigkeitsverlusten führen, wenn eine Abhängigkeit in einer älteren Version verbleibt und Libs aktualisiert werden.


Ansonsten ist es aber auch nicht wesentlich anders als
pkgsrc/mk/bulk/*sandbox*
 
Danke für die Infos!

Danke Leute!

Das pkg_chk auch mit "make update" arbeitet wusste ich nicht (stand nicht in der "man").
Ich werde mir dann man die Sandkisten-Geschichte (http://www.bsdfreak.org/modules/news/article.php?storyid=1) näher ansehen. Dieses "Update-Script" auf "http://www.coolfactor.org/~gavan/update/" scheint da schon ein guter Schritt in die richtige Richtung zu sein. Ich sehe es mir mal genauer an.

Was ich nur noch nicht ganz verstanden habe:
mit "pkg_chk -g" wird eine "pkgchk.conf" erstellt, die die ORIGIN's aller installierten Packages enthält (ich glaube sogar in der Reihenfolge der Abhängigkeiten).
In der Man-Page steht, das man dahinter einen Rechnernamen angeben kann/muss.

Was bewirkt dieser Rechnername in der Datei??? Ich dachte man arbeitet mit diesen Tools nur local... :confused:
 
kaishakunin schrieb:
Naja, ich weiß nicht ob es immer 100% glatt geht wenn man die erfolgreich gebauten Pakete einspielt. Könnte wieder zu Abhängigkeitsverlusten führen, wenn eine Abhängigkeit in einer älteren Version verbleibt und Libs aktualisiert werden.
Zum Vergrößern anklicken....

Ja, deshalb ist das von dem Script auch nicht vorgesehen :)
 
quarzsnoopy schrieb:
Was ich nur noch nicht ganz verstanden habe:
mit "pkg_chk -g" wird eine "pkgchk.conf" erstellt, die die ORIGIN's aller installierten Packages enthält (ich glaube sogar in der Reihenfolge der Abhängigkeiten).
In der Man-Page steht, das man dahinter einen Rechnernamen angeben kann/muss.

Was bewirkt dieser Rechnername in der Datei??? Ich dachte man arbeitet mit diesen Tools nur local... :confused:
Zum Vergrößern anklicken....

Ich habe pkg_chk schon seit geraumer Zeit nur noch benutzt um veraltete Pakete zu finden, aber IMO ist der Rechnername nützlich wenn pkgsrc via NFS für mehrere Clients bereitgestellt wird.

Ansonten sein nochmal darauf hingewiesen das ich die Updates in chroot im Wiki beschrieben habe ;-)
 
mawei schrieb:
Ja, deshalb ist das von dem Script auch nicht vorgesehen :)
Zum Vergrößern anklicken....

Es gab mal Diskussionen zur Automatisierbarkeit der Abhängigkeitsauflösung, allgemeiner Konsens war am Ende das nur Brain 1.0 das vernünftig hinbekommt ;-)
 
quarzsnoopy schrieb:
Das pkg_chk auch mit "make update" arbeitet wusste ich nicht
Zum Vergrößern anklicken....

Wusste ich auch nicht. Zumal in der man page ausdrücklich steht

"When updating packages that depend on each other pkg_chk will skip depen-
dent packages to reduce unnecessary rebuilding."
 
kaishakunin schrieb:
Ich habe pkg_chk schon seit geraumer Zeit nur noch benutzt um veraltete Pakete zu finden, aber IMO ist der Rechnername nützlich wenn pkgsrc via NFS für mehrere Clients bereitgestellt wird.
Zum Vergrößern anklicken....

Ach so, zum automatischen verteilen im Netz.



kaishakunin schrieb:
Ansonten sein nochmal darauf hingewiesen das ich die Updates in chroot im Wiki beschrieben habe ;-)
Zum Vergrößern anklicken....

Hast Du auf WIKI nicht das mergen der etc-Dateien mit "etcupdate" vergessen zu beschreiben?
Manchmal ändert sich da ja auch ne Kleinigkeit (Scripte in Daily oder in einer Conf)...
 
kaishakunin schrieb:
Es gab mal Diskussionen zur Automatisierbarkeit der Abhängigkeitsauflösung, allgemeiner Konsens war am Ende das nur Brain 1.0 das vernünftig hinbekommt ;-)
Zum Vergrößern anklicken....

Ich kann mir nicht vorstellen, das es nicht zu automatisieren geht, die Arbeit wird doch von den pkgsrc-maintener'n schon geleistet, sonst könnten doch die Packages bei der Installation nicht ihre Abhängigkeiten auflösen. Diese Infos, in den pkgsrc's, reichen doch um was anständiges zu bauen.
Bei FreeBSD funktioniert das ja auch und (ich will es ja nicht erwähnen) es gibt ja sogar Linux-Distries, die das hinbekommen.

Naja, aber ich kann sowas nicht basteln und warte dann bis das einer macht, dessen Kopf grösser ist als meiner... :rolleyes:

Mein Brain hat da auch nen Augenblick gebraucht um auf den Versionsstand 1.0 zu kommen, um bei solchen Abhängigkeitsfragen halbwegs anständige Antworten geben zu können. ;)
 
quarzsnoopy schrieb:
Hast Du auf WIKI nicht das mergen der etc-Dateien mit "etcupdate" vergessen zu beschreiben?
Manchmal ändert sich da ja auch ne Kleinigkeit (Scripte in Daily oder in einer Conf)...
Zum Vergrößern anklicken....

Aber doch nicht bei pkgsr-updates, sondern nur bei Updates des Basissystems. Paket-dotfiles liegen eigentlich in /usr/pkg/etc
 
quarzsnoopy schrieb:
Ich kann mir nicht vorstellen, das es nicht zu automatisieren geht, die Arbeit wird doch von den pkgsrc-maintener'n schon geleistet, sonst könnten doch die Packages bei der Installation nicht ihre Abhängigkeiten auflösen. Diese Infos, in den pkgsrc's, reichen doch um was anständiges zu bauen.
Bei FreeBSD funktioniert das ja auch und (ich will es ja nicht erwähnen) es gibt ja sogar Linux-Distries, die das hinbekommen.
Zum Vergrößern anklicken....

Ich denke automatisieren kann man das schon, aber es ist halt auch nicht ohne ;-)

IMO sollte ein Schatten-build (quasi im chroot) ausreichen, wenn dessen Erfolg vor der Installation geprüft wird, also sicher ist das *alle* Abhängigkeiten funktionieren und hinterher nicht weniger Pakete da sind.
 
kaishakunin schrieb:
Ich denke automatisieren kann man das schon, aber es ist halt auch nicht ohne ;-)

IMO sollte ein Schatten-build (quasi im chroot) ausreichen, wenn dessen Erfolg vor der Installation geprüft wird, also sicher ist das *alle* Abhängigkeiten funktionieren und hinterher nicht weniger Pakete da sind.
Zum Vergrößern anklicken....


Jo! Mit den momentanen Mitteln ist das das Beste. Zuviel Arbeit ist das ja auch nicht, damit kann man leben. :)



Danke nochmal an ALLE, die hier gepostet haben! Das hat meinen Einstieg ein ganzes Stück weiter gebracht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben