d-u über GUI

[bluelupo]

Hi zusammen,
da ich gerade die neue Fedora16Alpha teste und dort mit KpackageKit ein GUI für das Systemupdate (äquivalent zu "yum update") existiert und gut funktioniert, frage ich mich warum dies nicht unter Debian machbar ist.

Kennt jemand den Grund warum Debian kein KpackageKit als Deb-Paket anbietet?

Ich will hier keine Diskussion oder "Glaubenskrieg" anzetteln warum den d-u auf der Kommandozeile durchführen sollte oder nicht, sondern die Vorteile einer "Systemupdate-GUI" für den nicht versierten User heraus stellen. Außerdem muss ich zugegeben das ich bei meinen Systemen eine "pflegleichte" Art doch sehr begrüßen würde ;-)

[dieres]

Ich kenne KpackageKit nicht, aber ich hoffe es ist in der Bedienung gelungener als synaptic, das gefällt mir nämlich gar nicht! Da finde ich apt auf Kommandzeile angenehmer.
Ansonsten fände ich ein DistUbgrade ohne in init 3 zu wechseln auch sehr angenehm. Aber wenn ich das richtig in Erinnerung habe, soll das an sid liegen. Den Grund dafür hab ich nicht mehr in Erinnerung.

[towo]

Der Grund ist relativ einfach.
Sid ist ein Rolling Release. Im gegensatz zu Distros, die ein festes Release-Schema haben, kommen hier immer mal wieder neue Versionen von Anwendungen. Das ist in der Regel kein Problem, es sei denn, es handelt sich zum Bleistift um den Xserver.
Der gesunde Menschenverstand würde hier aufmerken, daß es keine gute Idee ist, Selbigen zu aktualisieren, wärend er läuft. Is kann hierbei nämlich vorkommen. daß bei dieser Aktion der Server stirbt, was wärend eines Systemupdates fatale Folgen haben kann, da hier ein inkonsistentes System zurück bleibt.

[dieres]

Das klingt logisch, aber gilt das selbe nicht prinzipiell auch für testing oder stable? Oder ist dort von vornherein aus diesem Grund ein neuer xserver ausgeschlossen? Dann hätte ich das ganze endlich verstanden.

[towo]

Testing ist ähnlich.
In stable kommen nie neue Versionen rein.

[bluelupo]

Hi towo,
ich kann deine Argumente verstehen und nachvollziehen. Ich habe es unter Fedora KpackageKit getestet und dort waren, von der ISO-Installation (Alpha) ausgehend, mehrere hundert Pakete zu aktualisieren. Heute schon wieder mehr als dreißig und da waren bestimmt Libs dabei während das System lief im Zugriff.

Wie schaffen das die Jungs von Fedora? Fedora ist bekannt dafür das, auch wenn es keine RR Distro ist, relativ viele Programmupdates nach einer Veröffentlichung nachgeschoben werden.

[towo]

Das schaffen die Junngs von Fedora so lange, bis es eben schief geht.
Aber auch hier gilt, in der Regel kommen hier keine Major-Versions-Updates, somit ist das Risiko geringer, daß hier das System flöten geht.

[ralul]

@towo, wie soll das System dadurch flöten gehen, musst du genauer erklären.

- Der Grund für sidux war lange Zeit, das dbus neu gestartet wurde. Das ist aber mal letztes Jahr rausgeglogen aus der upgrade Routine. (Ein Restart des xservers wäre natürlich genauso fatal: Muss man mal in die Scripte der Pakete schauen...)

- Ein anderer Grund könnte sein, dass Packagekit kein dist-upgrade macht, sonder ein einfaches upgrade

Im Übrigen habe ich mit PackageKit auf allen Systemen nur schlechte Erfahrungen, bisher ...

[towo]

@towo, wie soll das System dadurch flöten gehen, musst du genauer erklären.

$Unbedarfter_User macht in solch einer Situation gern in aller Windows-Manier einen Reboot. das ist bei einem halbfertigen Update alles Andere, als eine tolle Idee.
Btw, ich mache d-u auch fast immer in X, per xterm, war aber das eine oder andere Mal froh, das Ganze in einem Screen gestartet zu haben.

[ralul]

@towo, "froh" heisst Dein xserver abgestürzt, neugestartet? Wie lange war das her, dieses Jahr noch?

[towo]

Ja, irgendwann dieses Jahr, war ein glibc-Update, wo einige Dienste restartet werden mußten, unter anderem gdm und das hatte X weggerissen.

[hefee]

die frage ist doch nicht wie oft es vorkommen kann, sondern das die Möglichkeit besteht - wenn halt ein XServer update in Sid reinkommt, das den alten XServer der gerade läuft, aus dem Tritt bringt, ist halt dein System Essig. Wie schon an vielen Stellen angemerkt: Sid muss von Debian Seite aus gesehen nicht tun - wieso willst du dich dann darauf verlassen, das jedes XServer Update auf ein irgendeine andere Version auch problemlos klappt? Schließlich reden wir davon, das mal menschen drei/vier Wochen kein update machen... Eine console & apt-get sind  essential Pakete - da wird viel Zeit reingesteckt, dass da kein kaputtes System zurück bleibt. Auch sind die Abhängigkeiten des XServers um ein vielfaches höher als die eines reinen apt-get. Warum es intrinsich mal Fehlschlagen muss / bzw. warum es oft klappt:
1. der XServer cacht alle libs zwischen die er benutzt hat eine Weile zwischen
2. du startest den update Prozess, nun werden libs verändert auf die der XServer zugreift
fast immer hast du Glück alle libs haben gleiche ABI oder sind noch zwischengecacht
ODER
der XServer versucht was von der neuen lib nachzuladen mit einer anderen ABI ->BÄM, oder der RAM wird andersweitig gebaucht, weil du nebenher noch einen Film schaust und der lib cache wird geleert oder oder oder...

Das Problem ist halt, dass dies äußerst schwer nachzuvollziehen ist, Fehler sind auch kaum zu reproduzieren, ...

Bei Stable bzw. festen Releasen ist das etwas anders: Hier wird ein Update von einer definierten Version zu einer Anderen einfach x-mal durchgespielt...

PS: Das Problem haben ALLE Systeme die ein Upgrade Prozess via X zulassen, deswegen überlegen viele Distris wie u.a. auch Ubuntu den Upgradeprozess beim runterfahren zu machen, wenn das X einfach nicht mehr läuft...

[holgerw]

Hallo Torsten,

Btw, ich mache d-u auch fast immer in X, per xterm, war aber das eine oder andere Mal froh, das Ganze in einem Screen gestartet zu haben.

Ich habe schon einige Male von openSUSE11.3 auf 11.4 aktualisiert unter laufendem xserver mit KDE, aber auch die konsole und zypper benutzt. Das lief immer reibungslos und dabei wurde garantiert massiv auf neue Versionen von Xorg und KDE aktualisiert.

Nach Aktualisierungen mit zypper kommt übrigens ein Hinweis, dass einige laufende Prozesse durch die Aktualisierung neu gestartet werden müssen, und ich mir die mit

Code Select Expand

zypper ps anzeigen lassen kann.

Viele Grüße,
 Holger

[ralul]

@Holger , das meinte ich: Die Erfahrung mit openSUSE und "zypper ps". Es gibt auch für apt so ein Tool (check-restart, oderso in einem Zusatz util Paket). Normalerweise, wenn ein Progi, oder xserver alle Libs geladen hat, und sei es nur ein Zeiger auf den Plattenplatz der Lib, macht ein Upgrade gar nichts - ausser wenn der Installer einen Restart eines Services macht - dann essig.

Aber eigentlich brauch man ja die upgegradeten Apps sowieso erst nach einem Reboot. Warum bieten wir nicht etwas in dieser Art:
Ein DU Button, alles wird runtergeladen beim Klick. Wenn alles da ist, wird ein halt.local Script geschrieben. Dieses führt mit den runtergeladenen Paketen das DU beim Shutdown durch. Der Nutzer erhält die Warnung: Upgrades beim Runterfahren stehen an!

[antitainer]

Warum bieten wir nicht etwas in dieser Art:
Ein DU Button, alles wird runtergeladen beim Klick. Wenn alles da ist, wird ein halt.local Script geschrieben. Dieses führt mit den runtergeladenen Paketen das DU beim Shutdown durch. Der Nutzer erhält die Warnung: Upgrades beim Runterfahren stehen an!

Die Idee find ich prinzipiell gut. Vor allem weil ich in letzter Zeit ziemlich faul geworden bin was D-U angeht  :oops:

Vor dem shutdown müsste dann bloß die Frage kommen, ob das D-U auch durchgeführt werden soll (wegen evtl. zu entfernende Pakete u.ä.)

Grüße
Marco