On 23-Oct-2000 Martin Stahn wrote:
"Heinz W. Pahlke" wrote:
wuerde ich doch lieber darauf verzichten. Und welche Bibliotheken tatsaechlich gerade gebraucht werden und deshalb nicht im normalen Betrieb geupdatet werden sollten, weiss ich ehrlich gesagt nur selten.
Also was gefaehrlich ist oder nicht duerfte SuSE wohl wissen ;-)
Sorry, da habe ich mich zu kurz ausgedrueckt. Ich meinte einfach, dass jeder Nutzer sehr unterschiedliche Programme am laufen hat. Es muesste also immer abgefragt werden, was gerade laeuft, damit eben z.B. keine fuer X notwendige Bibliotheken ausgetauscht werden, wenn unter X geupdatet wird.
Hauptsaechlich duerften das wohl die libc's sein, und evtl. noch einige andere.
War ja nur ein Vorschlag, ich zerbrech mir da schon laenger den
Fand ich doch gar nicht schlecht. Habe mir bloss einige moegliche Fallstricke ueberlegt. Vielleicht stimmen meine Ueberlegungen auch gar nicht.
kopf drueber. Bei Debian gehts ja imho. (habs aber noch nicht getestet in wie weit das wirklich funktioniert)
Kenne ich auch nur vom Hoerensagen.
Bibliotheken mehr. Und Du kannst auch sagen, dass Abhaengigkeiten nicht automatisch aufgeloest werden sollen, um das Update zu beschleunigen.
Deswegen ist die Kiste aber immer noch nicht am netz ;-) Diese
Aber es geht wesentlich schneller. Dass der Rechner fuer eine bestimmte Zeit nicht am Netz waere, liesse sich mit deiner Idee ja auch nicht grundsaetzlich verhindern.
Wie gesagt, mancher updated von der Konsole aus, andere von X-Window.
Wer redet von X ? Ich denke an meine Server und die haben kein X
Wenn es mehrere Update-Modi gaebe, waere es natuerlich am besten.
Einen Experten-Modus (die wissen, was sie tun, und die nicht auf
eine Klicki-Oberflaeche angewiesen sind), Yast1 (fuer diejenigen,
die nicht alles selber machen wollen, wobei Yast1 ihnen ruhig noch
ein paar mehr Wahlmoeglichkeiten einraeumen duerfte) und Yast2 (von
mir aus auch mit einer weiter automatisierten Konfiguration).
Der Trend scheint bei Suse wohl aber eher zu Yast2 zu gehen.
Gruss,
Heinz.
--
E-Mail: Heinz W. Pahlke