Komisch, dass Rolfs Beitraege einfach so "verschwunden" sind.
Ich wundere mich auch sehr...
Ich hole mal ein wenig aus, um möglichst viele von Deinen Fragen zu beantworten. Erstmal eine kleine Erklärung: Du musst zwischen einer Anwendung und dessen Konfigurationsdateien unterscheiden. Eine Anwendung liegt als Binärdatei in einem Pfad wie z.B. /bin oder /usr/bin (die Bedeutung der verschiedenen Pfade kannst Du Dir bei Gelegenheit »
hier« ansehen), während die Konfigurationsdateien (also: wie hat ein user sein Programm zuletzt verlassen, welche Einstellungen hat er festgelegt etc.) im /home des jeweiligen users zu finden sind. Da die Ordner bzw. Dateien zur besseren Übersicht versteckt werden (mittels eines →
.← Punkts am Anfang des Namens, z.B. /home/jhp/.mozilla) kannst Du diese normalerweise nicht sehen. In der Konsole sorgt ein '-a' als Parameter (ls -a), dass diese Dateien auch angezeigt werden, im Konqueror gibt es unter 'Ansicht' die Option "versteckte Dateien anzeigen".
Warum erzähle ich Dir das alles? Weil ich eigentlich nicht so richtig glaube, dass ein Up- oder Downgrade irgendetwas bei Dir ändern wird, denn ein Wechsel der Version betrifft zwar die Binärdatei, Bibliotheken und dergleichen, nicht aber diese Konfigurationsdateien - dies ist ja auch sinnvoll, sonst müsste man alle paar Tage (KDE wird z.B. laufend aktualisiert) seine Anwendungen neu einrichten.
Nun ist KDE ja nicht einfach nur so eine einzelne Anwendung, sondern ein ganzes Bündel davon; Fenstermanager, der Konqueror, der Kicker (unter Win auch "Taskleiste" genannt), kurz: alles, was Deine Arbeitsumgebung bestimmt (zumindest unter KDE, gibt ja auch noch andere Umgebungen). Wenn Du mal unter ~/.kde nachschaust siehst Du, das ein einfaches Löschen davon eventuell mehr Dinge beeinflusst, als Du möchtest. Es gilt hier also, spezifischer anzusetzen.
Das einzige Problem, welches Du konkret beschreibst, ist das mit den Namen in Deinem Menü - die Konfiguration Deines Menüs befindet sich in ~/.kde/share/config/kickerrc (die Tilde ~ steht für /home/$USERNAME), diese Datei würde ich mal verschieben (um sie bei Bedarf später wiederzuverwenden) und dann den Kicker mit dem Kommando
dcop kicker kicker restartneu starten, damit wird eine neue kickerrc angelegt.
Eine andere Möglichkeit wäre das testweise Anlegen eines neuen users, um zu sehen, ob der auch mit diesen Bugs zu kämpfen hat.
Die grafischen Fehler beschreibe mal bitte etwas genauer, das muss z.B. noch nicht mal an KDE liegen.
-bei einem Upgrade wird doch die komplette Version "ersetzt" und nicht "geflickt", oder sehe ich das falsch??
Naja, wie gesagt: KDE besteht aus vielen einzelnen Paketen, und welche von ihnen durch ein upgrade ersetzt werden, sagt Dir YaST ja. Oft werden nur einzelne Anwendungen aktualisiert, wenn jedoch ein Core-Paket wie 'kdebase' erneuert wird, werden alle davon abhängigen Pakete ebenfalls auf die neue Version gehievt (und das sind sehr viele).
Die andere Moeglichkeit waere, den von dir erwaehnten "Downgrade" durchzufuehren; wobei ich keine Ahnung habe, wie ich das machen soll.
Meinst du damit, dass ich die DVD einlegen und davon wieder das "alte" KDE installieren soll?
Nö, ich würde auf die Versionen der 'update'-Quellen downgraden. Wie gesagt, nimm' z.B. 'kdebase', stufe es auf eine Version aus 'update' zurück, der Rest wird folgen - ich finde jedoch, das ergibt zum jetzigen Zeitpunkt keinen Sinn (kannst es aber dennoch einfach mal ausprobieren, wer weiß?).
Bin absolut deiner Meinung, nur weiss man als "Frischling" aus der Windowswelt kommend nicht so recht, ob man mit diversen Versuchen und Experimenten dem System schadet oder hilft [...]
Linux verhält sich ziemlich konsistent - klar kann eine Neuinstallation unter Umständen einiges beheben, oft genug kommt aber exakt das selbe heraus und man hat damit nur Zeit verplempert. Zudem Kontrolle (z.B. zur Erlangung eines stabilen Systems) ja nun mal das entsprechende Wissen voraussetzt, und das erlangt man so richtig nur in der Praxis. Oder mal sorum: beim regulären Einrichten von Systemen nach Plan xyz lerne ich eigentlich garnichts. Ganz anders sieht es aus, wenn Probleme auftauchen, denn die haben *fast immer* einen irgendwie nachvollziehbaren Grund - behebt man die Ursache, hat man sein System wieder etwas besser kennen gelernt. Natürlich ist das ganze System derzeit noch 'ne Menge Heu für Dich, aber mit irgendwas muss man ja anfangen.
Zudem ist man sich dann auch sicherer, ob man gerade an etwas kritischen herumschraubt oder man ruhig mal etwas experimentieren kann, ohne sein System als ganzes zu gefährden.
Okay, soweit für's erste - zwei Sachen sind mir noch aufgefallen:
Ich habe lediglich alle Updates ueber runlevel 3 eingespielt [...]
Wieso das eigentlich? Aktualisierungen kannst Du ganz normal im Runlevel 5 durchführen lassen (und ein anschließender Neustart ist auch nicht nötig, es sei denn, Dein Kernel wurde aktualisiert). Die einzige Ausnahme, die mir einfällt, ist die Installation eines Grafikkartentreibers mittels einer .run-Datei, die muss im RL 3 vollzogen werden.
Folgende repositories sind bei Yast:
Yast Update
OSS
Nicht-OSS
[...]
Ist mit "YaST Update" denn *der* update-channel gemeint? Poste mal die Ausgabe von
zypper reposund packe diese in code-Tags, so wie »
hier« beschrieben.
Es ist sicherlich nicht so, dass ein stabiler Desktop auf KDE-Backports verzichten muss oder so. Ich verwende schon seit öhm... sehr langer Zeit die KDE-Backports und hatte bislang keine Probs mit denen. Jedenfalls nicht mehr als mit Paketen von Packman oder so.
