Aktualisieren von Programmen und System bei NetBSD

M

meilenstein

Well-Known Member
Hallo zusammen

eine ganz allgemeine Frage zum Aktualisieren des Systems bei NetBSD.

Wie ich heute gelesen habe ist vor kurzem der Stable Zweig auf pkgsrc-2016Q2 aktualisiert/festgesetzt worden. Jetzt habe ich heute einmal etwas quer gelesen und verstehe die Logik bei NetBSD noch nicht so wirklich.

Reicht es jetzt von pkgsrc-2016Q1 kommend, wenn ich einfach den pkgsrc Zweig aktualisiere bspw. mit
$ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -dP-rpkgsrc-2016Q2
und anschließend bspw. über pkgin update und pkgin upgrade die Programme aktualisiere? Oder muss ich dann das System und den Kernel zusätzlich noch aktualisieren. Oder wird dies mit erledigt?

Vielleicht könnt ihr mir ja einen Anhaltspunkt im Netz nennen, welcher mir den Einstieg erleichtert :-)
 
Also Pkgin und Pkgsrc sind zwei verschiedene Ebenen, Pkgin benutzt die Binaries von Pkgsrc. Wenn die gewünschte Version nicht in Pkgin verfügbar ist und auch der hinterlegte PKG_PATH hinsichtlich Binärpakete nix brauchbares beinhaltet, dann gehts nur über Pkgsrc und selber bauen. Alle registrieren sich bei der gleichen Stelle, damit's keine böse Überraschungen gibt.
Kernel, Userland leben von Pkgsrc komplett unabhängig, praktisch kannst du dein NetBSD auch über sysinst upgraden. Zuweilen bringen größere Änderungen ein Neubau von Paketen nach sich oder man muss ein paar Symlinks nachziehen.
 
Ah ok danke, hatte das mit pkgin und pkgsrc dann schon durcheinandergebracht, daher war es mich unverständlich.
Glaube ich lese die Anleitung von NetBSD einfach (noch) mal von vorne :-)
 
Jetzt habe ich doch noch eine Verständnisfrage.
Wenn ich mit pkgsrc nutze und dort in den jeweiligen Verzeichnissen dann "make install" eingebe stoße ich immer wieder auf den Fall dass mit einer Fehlermeldung stoppt.
Bsp.
Code: 
=> Automatic manual page handling
=> Creating binary package /usr/pkgsrc/archivers/libarchive/work/.packages/libarchive-3.2.1nb1.tgz
===> Installing binary package of libarchive-3.2.1nb1
pkg_add: A different version of libarchive-3.2.1nb1 is already installed: libarchive-3.1.2nb1
pkg_add: 1 package addition failed
*** Error code 1

Stop.
make[2]: stopped in /usr/pkgsrc/archivers/libarchive
*** Error code 1

Stop.
make[1]: stopped in /usr/pkgsrc/archivers/libarchive
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/archivers/libarchive
Jetzt habe ich in das entsprechende Verzeichnis gewechselt und das Paket mittel "pkg_add -uu" installiert.

Irgendwie umständlich, oder was mach ich falsch?
Bei "make update" habe ich gelesen, dass dies wohl nicht ganz unproblematisch ist, daher die Frage, wie müsste ich alternativ vorgehen um aktuelle Pakete installieren (aktualisieren) zu können? Bin irgendwie von der Vielzahl der Möglichkeiten erschlagen :-)
 
Zeig doch mal die Stelle wo das steht dass make update problematisch ist(keine Ahnung worauf das sich bezieht). Denn make update ist der normale Weg ein installierte Paket über Pkgsrc zu aktualisieren.
 
Über lintpkgsrc -i kann ich mir ja anzeigen lassen welche Programme alle veraltet sind. Ich leite mir die Ausgabe in eine Textdatei um und gehe dann auf pkgsrc.se und schaue dort nach dem Pfad für die jeweiligen Programme :-)
Kann ich die Pfadangaben zu den jeweiligen Programmen auch irgendwie eleganter rausbekommen? Und kann man jetzt irgendwie alle Pakete automatisiert aktualisieren?
 
na aber dann drehe ich mich im Kreis :ugly:

Code: 
pi2_armv7# lintpkgsrc -i
[...]
Version mismatch: 'python27' 2.7.11nb2 vs 2.7.12nb4
Version mismatch: 'readline' 6.3nb3 vs 7.0
Version mismatch: 'revbump' 2.12 vs 2.14
Version mismatch: 'texlive2pkg' 1.1 vs 1.1nb1
Version mismatch: 'wget' 1.18 vs 1.18nb2
Version mismatch: 'xorg-cf-files' 1.0.6 vs 1.0.6nb1
pi2_armv7# pkgin update
processing remote summary (ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/earmv7hf/7.0/All)...
database for ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/earmv7hf/7.0/All is up-to-date
pi2_armv7# pkgin upgrade
nothing to do.
 
warum? soll ich den Vorschlaghammer auspacken? ;)

Server sollte der richtige sein, hab im FTP Verzeichnis geschaut und hier gibt es einfach keine Builds ...
 
Dazu mal 'ne dumme Frage von 'nem blutigen Anfänger, der gestern seine Erstinstallation gemacht hat:
Der aktuelle stabile Zweig ist ja 7.0-2016Q3. Dort sind aber nur wenige Pakete aufgeführt. Es ist schon so gedacht, daß ich in meiner "repositories.conf" unter ".../7.0-2016Q3/All" noch ".../7.0-2016Q2/All" stehen haben sollte, vielleicht auch ".../7.0-2016Q1/All", als Fallback; oder? Komisch nur, daß die Dokumentation nichts dergleichen sagt. Oder soll man alle in Q3 fehlenden Pakete selbst kompilieren?
 
@meilenstein: Bin gerade nicht sicher ob ich das als Sarkasmus werten muss. Du suchst doch gerade nach einen Möglichkeit all deine Pakete zu aktualisieren und hast bereits die Liste der zu aktualisierenden Pakete. Jetzt möchtest du dir ein Skript basteln, was dessen Ausgabe parst und jedes neue Paket herunterlädt. Genau das alles macht pkg_chk ohne zu frickeln. Andernfalls wäre sed oder besser awk was für dich um zeilenweise die Liste abzuarbeiten.

@Tronar: Beziehst du dich auf repositories.conf von pkgin? Da steht doch oben als Kommentar: Pkgin repositories list Simpy add repositories URIs one below the other

Oben stehende haben höhere Priorität.
 
:rolleyes: hatte mir seiner Zeit für pkg_chk - warum auch immer - was falsches in meiner Anleitung notiert (Mitschrift der Installation), daher hatte ich dieses Programm ausgeschlossen und war auf pkgin fixiert, welches ja eben nicht funktioniert. pkg_chk macht aber ja genau das was es soll, insofern danke Dir für den Hinweis!
 
Es ging nicht darum, wie man pkgin benutzt; es ging darum, welche Repositories richtig und ratsam sind. Ich hatte es in dieser Reihenfolge, Q3-Q2-Q1, und dann fing pkgin an zu spinnen. Er wollte für die Installation irgendeines Witzpakets 11 GB Plattenplatz und beschwerte sich, daß auf Partition a nicht genug sei. Ich habe tatsächlich angefangen umzuräumen, um Platz zu schaffen, bevor ich darauf kam, daß man den anders kurieren muß. Ich löschte dann einfach die /var/db/pkgin/pkgin.db. Diese wurde bei nächster Gelegenheit neu erstellt, und seitdem funktioniert alles.
Nur als Geheimtip fürs Protokoll: Es kommt vor, daß sich pkgin beim Hinzufügen von Repositories verschluckt und die Datenbank kaputt macht. Die muß man dann löschen.

Edit: Gibt es eine einfache Möglichkeit, die Installationsmeldungen der ganzen Pakete noch einmal zu sehen? Also z. B. den Hinweis beim Mozilla-Zertifikatspaket, man müsse irgendein Skript aufrufen, um die ganzen Hashes zu erzeugen, u. dgl. Im Errorlog in /var/db/pkgin stehen leider nur die Fehler- und Warnmeldungen.
 
Korrektur! "Seitdem funktioniert alles"? Denkste! Es kam genau so, wie ich befürchtet hatte. Verschiedene Pakete in Q3 haben Abhängigkeiten, die sich in Q3 nicht erfüllen lassen, für die aber wiederum die Pakete in Q2 oder Q1 zu alt sind. Ohne Kompilierorgie geht da nichts, aber das ist für Pakete mit extrem vielen Abhängigkeiten, z. B. im Umfeld von Gnome, nicht praktikabel.
Habe ich da was übersehen? Wie macht Ihr das? Benutzt überhaupt einer von Euch Binärpakete?
 
Wie gesagt, ich nutzte NetBSD bisher nur am Raspberry Pi 2 mit ARM v7 Architektur. Hier gibt es leider (noch) keine Binärpakete. Ich denke abhängig von der Architektur die Du verwendest sollte es schon auch Binärpakete für 2016-Q3 geben.
 
Ich benutze nur Binärpakete, gerade weil diese oft eklige Abhängigkeiten haben, die mein Laptop mehr als 5min beschäftigen würden. Vermutlich ich auch nicht der klass. Standardnutzer aber Pkgsrc kann manchmal ziemlich zickig sein wenn nur ein Teil aktualisiert ist.
@Tronar: Hast du ein Beispiel für ein Paket mit so einem Infotext?
 
Okay, das mit dem Infotext hat sich erledigt: pkg_info -aD
Ist wahrscheinlich das Gleiche wie unter FreeBSD, aber da mußte ich es nie benutzen, weil ich durch die Ausgaben zurückscrollen konnte. Außerdem ist FreeBSD stärker automatisiert, da machen die Paketskripte vieles von allein.

Zu den Abhängigkeiten:
Ich habe mir vorgestern Ekiga installiert oder es jedenfalls versucht. Das ist wohl der einzige SIP-Client unter NetBSD, abgesehen von ein paar halbgaren Programmen im WIP-Bereich. Ekiga ist ein Gnome-Programm, d. h. es zieht als Abhängigkeit den ganzen Gnome-Desktop mit hinein samt Gnome-Shell, Spidermonkey und pipapo bis hinab zur Bash. Summa summarum 250 MB IIRC. (KDE-Programme sind dagegen wahre Lämmer!)
Ekiga selbst steht im Zweig Q1, aber für etliche seiner Abhängigkeiten gab es Aktualisierungen in Q2 oder Q3, und die wurden von Pkgin natürlich bevorzugt installiert. Diese installierten wiederum Abhängigkeiten aus Q1 und beklagten sich dann, diese seien zu alt, so in der Art "could not find version libXYZ>=2.3.4". Es wäre natürlich auch eine gute Idee gewesen, daß Pkgin das Vorhandensein aller Abhängigkeiten feststellt, bevor er anfängt, irgendwas zu installieren. Da ist Einiges ganz schlecht durchdacht.

Jetzt sag mal konkret, wie Du das machst, darktrym, wenn Du Binärpakete aktualisierst, und auch, welche Repositories Du in welcher Reihenfolge benutzt. Downgradest Du dann eventuell Pakete wieder von Hand, wenn die Abhängigkeiten nicht hinhauen?
 
Kleines Update: Die Abhängigkeiten in den Repositories scheinen doch alle zu stimmen. Es ist offenbar nur Pkgin, was Probleme verursacht.
Ich habe mir die Fehlermeldungen mal genau ungeschaut und gemerkt, daß oft alte Pakete aus Q1 installiert werden, obwohl neuere aus Q3 vorhanden sind. Ein »pkgin upgrade« brachte nichts, erst ein wiederholtes »pkgin full-upgrade« in Verbindung mit abermaligem Löschen der Datenbank hat alle Pakete aktualisiert und fast alle Fehler beseitigt. Aber ich weiß immer noch nicht, ob es an Pkgin allein liegt oder ich irgendwas falsch mache.
Ich muß mich in absehbarer Zeit an die Maintainer wenden; zuerst arbeite ich mich mal ins System ein.
 
Wenn meine Datenbank nicht up-to-date wäre, würde »pkgin full-upgrade« doch auch nicht funktionieren. Oder arbeitet der Befehl an der Datenbank vorbei?
Im Moment kann ich das nicht überprüfen, jetzt hab' ich ja alles auf Aktuell geprügelt. Aber wenn ich wieder auf dasselbe Problem stoße, achte ich darauf.
 
Ich hatte zwischenzeitlich das Problem, dass der Repo Pfad sich aus der Architektur zusammengesetzt hat. Daher kannte er Pakete aber konnte diese nicht herunterladen. All das nur weil jemand meinte amd64 -> x86_64 in Pkgsrc ist folgenlos.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben