[DE] Upgrade-'Check'

[Isegrimm666]

Guten Morgen ...

Ich denke, hier ist der bessere Platz als in 'Upgrade-Warnings', zumal es ja eine Frage und keine Warnung ist 

Ich habe mir nach etlichen Fehlern die Ratschläge aus dem 'Upgrade-Warnings'-Thread zu Herzen genommen und mache von einem Upgrade immer eine Kontrolle:

1.

Code: [Select]

doas apt update && doas apt --solver 3.0 full-upgrade
Ergibt die Ausgabe eine gewisse Anzahl zu löschender Pakete, dann breche ich ab und checke, ob sich bei den zu installierenden oder abzudatenden Paketen ein Equivalent zu einem zu löschenden Paket befindet. Gibt es das nicht, gehe ich auf Nummer sicher und mache nur ein:

2.

Code: [Select]

doas apt --solver 3.0 upgrade
(... wobei man natürlich streiten kann, ob der solver hier Sinn macht.)

Manchmal sind die zu löschenden und upzudatenden Pakete so viel, dass ein Vergleich ziemlich mühsam ist.

Deshalb meine Frage:
Gibt es ein Script oder einen Befehl, der diesen Abgleich übernimmt und damit die Kontrolle einfacher - und sicherer - macht?

[unklarer]

...
Deshalb meine Frage:
Gibt es ein Script oder einen Befehl, der diesen Abgleich übernimmt und damit die Kontrolle einfacher - und sicherer - macht?

Das gibt es nicht.
Mache jeden Tag das D_U und die Zahlen werden übersichtlich. 

[hendrikL]

Nun, man kann sich etwas basteln --> dort sind zwei Wege zu vergleichen, es müsste nur alles etwas angepasst werden, viel Spaß beim Basteln --> https://forum.siduction.org/index.php?topic=9297.msg73874#msg73874
Also die gegenüberzustellenden Pakete mit der Hilfe von "diff"  vergleichen.

Was noch gesagt werden muss, ist, es werden auch manchmal Programme entfernt, die entweder nicht mehr gebraucht werden oder deren Funktion in eine andere Bibliothek eingebunden wurde oder gesplittet, z. B. login und login.defs.

Nur andauernd --solver 3.0 zu nutzen ist wirklich überflüssig und sinnfrei!

Und wer wirklich Sorge hat sein System zu zerschießen und zu lange wartet mit full-upgrade, der zerschießt sein System erst recht!
Ich möchte niemanden zu nahe treten, aber, da wäre es eine Überlegung wert entweder stable zu nehmen, mit backports oder ein unzerstörbares System zu nutzen, immuntable System genannt.
Also vor allem, wenn es um Alltags- und Arbeitsmaschinen geht.

Oder man hat eine VM, qemu z. B. , und testet erst mal was passiert wenn usw.

Dritte Möglichkeit das System mit btfrs und snapper aufsetzen, da könnte man im Notfall ein Rollback machen, siehe unser Manual/Handbuch --> https://manual.siduction.org/sys-admin-btrfs-snapper_de.html <-- Lesen ist auf jeden Fall notwendig!

[ro_sid]

[...]
Und wer wirklich Sorge hat sein System zu zerschießen und zu lange wartet mit full-upgrade, der zerschießt sein System erst recht!
Ich möchte niemanden zu nahe treten, aber, da wäre es eine Überlegung wert entweder stable zu nehmen, mit backports oder ein unzerstörbares System zu nutzen, immuntable System genannt.
Also vor allem, wenn es um Alltags- und Arbeitsmaschinen geht.
[...]

Nicht so ernst und schon gar nicht böse gemeint: Aber "immun" ist das System nicht - lediglich (lt. Behauptung) - unveränderbar "immutable" . Es ist aber eine interessante Wortschöpfung - eventuell urheberrechtlich zu schützen. Soweit ich weiß, betrifft es auch nur den Kernel (im RAM), nicht installierte/zu installierende Pakete.
Ziemlich immutable ist aber unser Siduction-Live-Image, solange es nicht installiert ist, also von (SS)Disk, Stick oder DVD läuft. Allerdings sind dann die Pakete zunächst nicht aktuell.

[hendrikL]

Yo. da hast Du recht, und ja, man kann alles kaputt machen.
Irgend ein geheim Rezept gibt es leider nicht.

[devil]

Und mal im Ernst: Viele Immutable-Projekte rücken langsam von der Bezeichnung ab, da es ja (zum Glück) einfach ist, aus r ein rw zu machen. Die Tendenz geht eher dahin, solche Projekte als atomar bzw. atomic zu bezeichnen.