Siduction Forum

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 ;-)

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.

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.

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.

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

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.

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.

@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 ...

Quote@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.

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

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

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...

Hallo Torsten,

QuoteBtw, 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 zypper ps anzeigen lassen kann.

Viele Grüße,
 Holger

@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!

Quote from: "ralul"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

Hi,

war da nicht auch das Problem daß, wenn bestimmte Sachen schief gehen -frag mich jetzt bitte niemand was genau, ich erinnere mich nur daß da mal irgendwas im Forum zur Sprache kam- und noch kein reboot durchgeführt wurde, es noch möglich war das System wieder zu reparieren aber nach einem reboot das schwierig, bzw für den nicht sehr versierten Nutzer so gut wie nicht möglich war? Irgendwas mit dpkg oder apt?

Falls ich mich da richtig erinnere finde ich daß "init 3" nicht soo schwierig ist wenn es sicherer ist.

Gruß
ayla

@ayla, ja für schief gehende DUs müsste man ein Notstartsystem - iso-Live-rescue - haben, oder ein Btrfs-snapshot feature, mit dem man den Vortagesstand wiederherstellen kann.

Hallo,

im Zusammenghang mit Aktualisierungen unter X gab es früher Diskussionen, damit meine ich nicht diese hier, in denen das als schlimmes Horrorszenario dargestellt wurde. Dabei beschränkte sich mancher nicht nur auf Debian. Aber das unterstellt dann, dass etwa die Distributoren von openSUSE in Kauf nehmen, dass Anwender ihr System zerlegen können. Ich lese ja schon einige Zeit auch zu openSUSE, dass bei einem DU unter X ein System halb geschrottet wurde, habe ich noch nirgendwo gelesen.

Auch größere Deaktualisierungen gehen übrigens ohne Schwierigkeiten. Unter laufendem KDE 4.7 habe ich bei drei PCs auf KDE 4.6 deaktualisiert.

Wenn das unter Debian Sid brisant ist, werte ich das nicht als schlecht, dann ist das eine Eigenart von Sid. Ich nutze Debian Sid und openSUSE, daher interessiert mich hier: Was läuft unter dem Nürnberger Linux anders, dass es dort offenbar nicht brisant ist? Und von statischer Distribution kann man bei meinem openSUSE nicht mehr sprechen, schon über das extra KDE Repo kommen häufig große Mengen neuer Versionen, und die lasse ich immer unter laufendem KDE durchführen.

Viele Grüße,
 Holger

Quote from: "holgerw"Hallo,
[...]
Wenn das unter Debian Sid brisant ist, werte ich das nicht als schlecht, dann ist das eine Eigenart von Sid. Ich nutze Debian Sid und openSUSE, daher interessiert mich hier: Was läuft unter dem Nürnberger Linux anders, dass es dort offenbar nicht brisant ist? Und von statischer Distribution kann man bei meinem openSUSE nicht mehr sprechen, schon über das extra KDE Repo kommen häufig große Mengen neuer Versionen, und die lasse ich immer unter laufendem KDE durchführen.

Viele Grüße,
 Holger

Hi Holger,
das sehe ich für Fedora genauso (vor kurzem gestestet) wenn man den Entwicklerzweig (Rawhide) nutzt. Dort kommen laufend neue Versionen herein, die mit GUI KpackageKit im laufenden Betrieb upgedatet werden.

Ich schätze das Risiko bei SuSE, Debian oder Fedora nicht unterschiedlich ein, aber Debian (SID) muss meiner Meinung etwas anders machern als SuSE und Fedora bei Aktualisierungen unter einen laufenden X. Ich bin leider kein Spezialist der dies grundlegend beurteilen kann :-(

Der Unterschied zwischen Sid und OpenSuse;fedora etc. ist, das die Matainer von Debian davon ausgehen, das es in der Konsole geschieht und auch das Sid auch mal ein kaputtes System hinterlassen darf. Sid ist der unstable Teil von Debian und wird von den Mantainern nicht empfolhen als System zu installieren :)

Bei OpenSuse und Fedora gehen die Mantainer davon aus das die Aktualisierung aus X herhaus geschieht, bzw. funktionieren soll -> Mit dieser Masgabe können die Aktualisierungen sorgen, das dies auch klappt.

Hi hefee,
okay die logischen Gründe der Maintainer sind mir schon bekannt aber warum sperren sich die Debianer dermaßen gegen eine Vereinfachung eines d-u oder machen die technisch gesehen den Systemupdate gänzlich anders. Eine hundertprozentige Sicherheit gegen kaputte Systeme kann's nicht geben weder bei Fedora, Suse oder Debian.

Update beim Runterfahren: Jo klar, dann vertippst Du Dich oder aber liest nicht, was er updaten will. Und beim nächsten Start bleibt der Rechner stumm.

Weit hergeholt, aber solange die Kiste noch läuft, ist es manchmal so, dass man im Fall der Fälle wirklich weniger Arbeit hat. Und noch was fällt mir in dem Zusammenhang noch ein: Wenn ich die Kiste ausschalte, hat das einen Grund: Ich habe keinerlei Böcke mehr, mich mit dem Ding zu beschäftigen. Mögliche Meldungen treffen dann auf ungefähr diese Aufnahmebereitschaft: Scheiss drauf, Feierabend. :)

@Bluelupo: Die Buben sind halt ein wenig konservativ. Es ist auch eigentlich egal, dass man stable ohne X aktualisieren soll. Der läuft auf stable-Maschinen meist eh nicht :). Und Testing und Sid sind den Buben egal.

Hi,

ich habe hier ein Epidemic GNU/Linux, ein brasilianisches Mini-Debian, das auf testing basiert.
http://www.epidemiclinux.org/
Epidemic hat ein graphisches Update-Tool namens eUpgrade. Die aktuelle Version 3.2. ist kurz nach dem Ende des Freeze von squeeze herausgekommen. In dieser Zeit sind zwei Versionssprünge von KDE und mehrfach xserver.xorg hereingekommen. Alles wäre gutgegangen, wenn nicht der Maintainer von libpam0g hart kdm gestoppt und neu gestartet hätte. Dadurch sind dann die Systemaktualierungen reihenweise gecrasht und haben genau das beschriebene Chaos hinterlassen.

Im aktuellen Stand ist libpam0g gefixt, so daß eine direkte Aktualisierung von Null möglich wäre. Nur hat James Benedito, der Chefentwickler, gerade die Anwendung im Repo gesperrt. Das ganze funktioniert deswegen, schätze ich, weil die Programme im Speicher sind und eben nicht von der Platte geladen werden. Es geht ja auch eine Aktualisierung von apt-get selbst. Nach den gängingen Erklärungen müßte ein Upgrade von apt-get selbst in der Textkonsole crashen.

Die Distro läßt sich auf Englisch installieren, und ich bin dabei das ganze ins Deutsche zu übersetzen.
Linux-Forum.de: Epidemic GNU/Linux - Ein ansteckendes Erlebnis (http://www.linux-forum.de/epidemic-gnu-linux-ein-ansteckendes-erlebnis-1971381.html)

Viele Grüße
Bequimão

Es ist auch gar nichts gegen den Sinn oder Unsinn eines grafischen Wrappers zu sagen, die Erfahrung lehrt aber, dass komplexe Systeme komplexere Fehler erzeugen.

Aus dieser Sicht von DonKult über die "Primitivität" von apt-get muss ich sagen: Der Mann hat recht. Definierte "Blödheit" ist mir an dieser Stelle lieber, das reduzieren der Nutzungsumgebung auf den einfachsten Fall ist auch keine schlechte Idee.

Ich kann mich nicht daran erinnern, jemals X verlassen zu haben, um irgendwas upzudaten, zumindest nicht freiwillig. Selbst meinen geliebten Catalyst ziehe ich im laufenden Betrieb hoch. Dass ich dann doch noch ein wenig "Windows-Jünger" geblieben bin, zeigt sich in einem darauffolgenden sauberen Neustart. Diese Minute nach gravierenden Änderungen sollte schon drin sein.

Eventuelle Reparaturen macht man dann halt wieder in der Konsole oder im Rettungssystem. Man will ja nicht aus der Übung kommen. :) Vielleicht nicht ganz so provokativ, aber eventuell wahr: Je einfacher und "benutzerfreundlicher" ein Update um die Ecke kommt, desto höher ist die Chance, dass $user den nicht mehr ernst nimmt. Mit teilweise fatalen Folgen.

Also ich hab es mir so eingerichtet:
Auf meiner zweiten Arbeitsfläche startet immer automatisch die konsole .. sie ist so eingerichtet, das sie immer an der selben stelle und die selbe größe hat und für die Optik ist die Umrandung weg (eigendlich das selbe was plasmcron macht, nur gabs da hin&wieder zuviel probleme mit den scriptengines).

so sieht das dann aus (zum vergößern: rechtsklick, grafik anzeigen):
(http://www.dritimage.de/uploads/bilder/131784394621_Bildschirmfoto43.jpeg)


So .. dort mach ich Täglich, stündlich .. wie Lust und laune die update-kontrolle.

Um es einfacher zu machen, arbeite ich mit "aliase" .. also

update = apt-get update && apt-show-versions -u
upgrade = apt-get dist-upgrade -d

Wie mensch sieht, ziehe ich die Packete nur runter, ohne installation.

Und dann hab ich die möglichkeit wann immer ich will das DU durchzuziehen. Da ich meinen rechner aber auch nicht ständig neu starte, passiert das vielleicht alle 3-4 Tage und da mach ich dann ohne X schnell und unkompliziert mein DU auch wieder mittels alias:

disu = apt-get dist-upgrade

Und warum erzähle ich euch das alles? ;)
Weil ich finde das ist genauso einfach und/oder so schnell wie ein evtuelles Upgradetool das die updates mit nachfrage beim runterfahren installieren soll. Nur das ich weiterhin jede kontrolle bei mir hab ..... ;)

Nur mal ein Gedanke so in die Runde geworfen ... ;)

reddark +1, so ähnlich mach ich's auch, bei mir ist es das Script /usr/local/sbin/agudu (von  apt-get update dist-upgrade):

apt-get update
apt-get -d -y dist-upgrade
for HOLD in $(dpkg --get-selections | grep hold | cut -f1); do apt-cache policy $HOLD; done

und zeigt gleich noch (eventuelle) holds an. ;)

Das eigentliche dist-upgrade passiert dann auf der <ALT><CTRL><F1>-Konsole, wenn nur "pipifax" aktualisiert wird bei laufendem X - wenn xserver oder ähnliche Pakete dabei sind, wird per "init 3" X runter und hinterher per "init 5" wieder hochgefahren (ja mein slim bzw. gdm ist nur im Runlevel 5 aktiv).

Ciao, Martin