ein Update mit smart wieder rückgängig machen, wie ?

[Ganymed]

Hi,
nachdem ich ein Update von KDE mit smart durchführe starte ich immer parallel zur laufenden Sitzung eine Neue. Wenn diese dann problemlos startet und bedienbar ist, sollte die Installation richtig abgelaufen sein.

Bis jetzt hat alles gut und ohne Probleme funktioniert - klopf auf den Holzkopf.

Auf Grund verschiedener Probleme mit meinem Palm und dem KDE-Pim Kontakt würde ich auch mal diese "Bastelstube" http://software.opensuse.org/download/KDE:/KDE3/openSUSE_10.2/ - (ganz bestimmt nicht abfällig gemeint und auch nicht auf meinem Mist gewachsen) aufsuchen.

Was muss ich tun, den vorherigen Zustand wiederherzustellen wenn etws schief geht?

Danke, Gruß Ganymed

 

[b3ll3roph0n]

nachdem ich ein Update von KDE mit smart durchführe [...]

Rein aus Interesse ...
... welche Quellen benutzt du denn für dein "Update von KDE", wenn nicht die aus dem Build-Service?

(ganz bestimmt nicht abfällig gemeint und auch nicht auf meinem Mist gewachsen)

Das trifft es ziemlich genau.
Lesen: KDE 3.5.7

Was muss ich tun, den vorherigen Zustand wiederherzustellen wenn etws schief geht?

Das letzte Backup einspielen.

Ein Downgrade mag bei einzelnen Paketen funktionieren, aber bei großen Teilen des Systems (KDE), kann das auch schief gehen.
Grund:
Neuere Pakete "wissen", in welcher Art und Weise sie sich von den alten unterscheiden und können dementsprechend notwendige Anpassungen in den Postinstall-Scripten vornehmen.
Umgekehrt gilt das nicht, ein altes Paket kann nicht mal ansatzweise "wissen", was sich in neueren Versionen desselben Pakets ändert und die Änderungen deshalb auch nicht wieder rückgängig machen.

 

[oc2pus]

...

Was muss ich tun, den vorherigen Zustand wiederherzustellen wenn etws schief geht?

Das letzte Backup einspielen....

es reicht ein

rpm -qa | sort > zustand-vor-update.txt

und nach dem update ein

rpm -qa | sort > zustand-nach-update.txt

mit

rpm -qa --last | less

kann man sich die zuletzt installierten Pakete anschauen.

Im Falle eines Falles werden diese dann eben wieder durch ihre Vorgänger ersetzt. Die Liste der Vorgänger erhält man durch einen "diff" der beiden obigen Listen. Z.Bsp mit kompare

 

[Ganymed]

Hi b3ll3roph0n
sei mir wegen meiner Formulierung nicht böse. Bei anderer Gelegenheit habe ich Deinen jetzt verlinkten Thread gelesen und kann Deine Anspannung verstehen.

Wenn etwas recht lange gutgeht wird man leichtfertiger; deshalb die Frage wenn etwas schief geht.

@oc2pus
Danke das liest sich jetzt so einfach, mir fehlt schlicht die Fantasie solche Anweisungen zu entwickeln.

Gruß Ganymed

 

[b3ll3roph0n]

sei mir wegen meiner Formulierung nicht böse. Bei anderer Gelegenheit habe ich Deinen jetzt verlinkten Thread gelesen und kann Deine Anspannung verstehen.

Bin ich nicht ...
Ich bin froh, dass meinen Warnungen auch mal gelesen werden.

Wenn etwas recht lange gutgeht wird man leichtfertiger;

Richtig.
Die KDE-Pakete aus dem BS laufen i.d.R. ganz gut, wenn aber mal ein Bug auftritt, dann bricht hier bei allen Usern die große Panik aus (Bsp: die momentanten Probleme mit artsd oder die Probleme mit dem Networkmanager vor kurzem) - daher meine ständigen Warnungen/Hinweise.

Danke das liest sich jetzt so einfach, mir fehlt schlicht die Fantasie solche Anweisungen zu entwickeln.

@oc2pus
Korrigier mich wenn ich falsch liege, aber beim Upgrade auf eine neue Version werden z.B. auch die Konfigurationsdateien entprechend angepasst - beim Downgrade werden derartige Änderungen nicht wieder rückgängig gemacht.
Bei größeren Änderungen (die im BS durchaus vorkommen könnten) kann das durchaus zu Problemen führen ...


@Ganymed
Ein Downgrade auf eine niedrigere Version sollte klappen (haben hier im Forum auch schon einige User erfolgreich durchgeführt) ... garantieren kann dir das aber niemand ...

 

[oc2pus]

@oc2pus
Korrigier mich wenn ich falsch liege, aber beim Upgrade auf eine neue Version werden z.B. auch die Konfigurationsdateien entprechend angepasst - beim Downgrade werden derartige Änderungen nicht wieder rückgängig gemacht.
Bei größeren Änderungen (die im BS durchaus vorkommen könnten) kann das durchaus zu Problemen führen ...[/quote]

1.) wir machen ja keine (grossen) Versionsprünge :mrgreen:
2.) rcrpmconfigcheck (als root ausgeführt) zeigt dir doch die geänderten Konfig-Dateien. Das Problem welches du ansprichst kommt ja meist daher, das man seine Konfig NICHT an die neue Version anpasst. RPM kopiert die aktuelle nach xxx.rpmsave und die neue nach xxx.rpmnew, normalerweise muss man dann die aktuelle xxx Konfigdatei an die xxx.rpmnew anpassen. Wenn ein Paket eine Konfig ersetzt, hat man seine alte Version immer noch in xxx.rpmsave und kann die zurückkopieren. Betroffenes Problemkind ist oft /opt/kde3/share/config/kdm/kdmrc.rpmnew bzw kdmrc.rpmsave. Aber wie gesagt, ein erfahrener Linux-Benutzer weiss das und vergleicht die nach jedem update und hat dann auch (fast) nie Probleme.

Natürlich ist das Handarbeit, aber wir reden ja hier mit erfahrenen Linux-Benutzern, die sowieso immer ein backup haben und wissen was sie tun. Oder warum sonst, will jemand immer die neueste Version haben ?
In 90% aller Fälle sind da eh nur Kleinigkeiten angepasst worden. Was steht ja in den Changelogs bzw release-Notes, die man natürlich vorher gelesen hat :mrgreen:

 

[b3ll3roph0n]

Aber wie gesagt, ein erfahrener Linux-Benutzer weiss das und vergleicht die nach jedem update und hat dann auch (fast) nie Probleme.

Ja, der erfahrene Benutzer weiß das ...
... wir wissen aber auch wie die Realität aussieht (= welche User sich i.d.R. diese Pakete installieren) ... :roll:

In 90% aller Fälle sind da eh nur Kleinigkeiten angepasst worden. Was steht ja in den Changelogs bzw release-Notes, die man natürlich vorher gelesen hat :mrgreen:

PS: Thx für den Tipp mit rcrpmconfigcheck - das kannte ich tatsächlich noch nicht.