Hallo Ich habe da eine Verständnisfrage und möchte damit die Unklarheiten für mich beseitigt haben. Es geht um rpm und allgemeine Updates. Mir wurde mal geraten, dass wenn ich ein Update von irgenden einem Programm mache, dass ich dann die alte Version zuerst deinstallieren soll. Irgendwie möchte ich das nicht schlucken. Ist das wirklich so ? Und wie sieht das bei Programmen aus, die ich selber kompiliere ? Und zum Schluss noch die Frage. Ich habe hier einen Suse 7.0 Server mit allen möglichen Diensten eingerichtet. Bin erst etwa seit einem halben Jahr mit Linux dabei und musste mir das mit viel, sehr viel lesen aneignen. Nun möche ich auf Suse 7.1 bzw. 7.2 updaten. Nun habe ich aber gelesen, dass Suse da einige Pfade geändert hat und ich muss zugeben, dass ich z.B. unfähig bin irgendwelche Dinger in den richtigen Runlevel zu kopieren. Damit habe ich (noch) null Durchsicht. Kurz: Würde so ein Update klappen ? Auf dem Suse 7.0 läuft z.B. Sendmail/Fetch-,Procmail mit Mailgate (Virenscanner), Apache, PHP/mysql, Samba, Netatalk, Backupserver, NFS, WU-FTP, APC-UVS, Printserver etc. Der Grund, warum ich updaten will ist eigentlich nur der, dass ich mit selbst kompilieren z.T. Noch sehr viel Probleme habe. Und ich Angst habe, dass ich meine Konfiguration nicht mehr hinkriege ;-)) Danke und Gruss Fabian
On 30 May 2001, at 18:42, Fabian Hüsser wrote:
Hallo
Ich habe da eine Verständnisfrage und möchte damit die Unklarheiten für mich beseitigt haben.
Es geht um rpm und allgemeine Updates. Mir wurde mal geraten, dass wenn ich ein Update von irgenden einem Programm mache, dass ich dann die alte Version zuerst deinstallieren soll.
Irgendwie möchte ich das nicht schlucken. Ist das wirklich so ?
Bei rpm nicht nötig. rpm wird, falls nötig, die alten Programmteile entweder überschreiben oder löschen. Ausnahme: Config-Dateien, die nicht überschrieben werden und mal als .rpmsave gesichert werden oder als .rpmnew als neues template abgelegt werden.
Und wie sieht das bei Programmen aus, die ich selber kompiliere ?
Das ist wohl 'ne Philosophiefrage: Wenn Du weißt, daß die neue Version die alte überschreibt und keine Leichen im Keller läßt, würde ich einfach drüber installieren. Falls nicht: Bei selbst kompilierten Programmen ohne rpm ist ein vollständiges deinstallieren unter Umständen sowieso Handarbeit. Das muß IMHO jeder selber für sich entscheiden.
Und zum Schluss noch die Frage.
Ich habe hier einen Suse 7.0 Server mit allen möglichen Diensten eingerichtet. Bin erst etwa seit einem halben Jahr mit Linux dabei und musste mir das mit viel, sehr viel lesen aneignen. Nun möche ich auf Suse7.1 bzw. 7.2 updaten. Nun habe ich aber gelesen, dass Suse da einige Pfade geändert hat und ich muss zugeben, dass ich z.B. unfähig bin irgendwelche Dinger in den richtigen Runlevel zu kopieren. Damit habe ich (noch) null Durchsicht.
Kurz: Würde so ein Update klappen ?
Bei mir hat der Update von 6.4 auf 7.0 (fast) problemlos funktioniert. Andere allerdinges haben hier von Schwierigkeiten berichtet. Allerdings sollte man sich nach dem Update alle Mails an root ansehen und(!) das System nach geänderten / neuen konfigfiles absuchen. Auch das hängt aber wieder vom Einzelfall ab. Wenn Du ein, sagen wir mal stark verhunztes System hast, ist eine Neuinstallation sicher einfacher. Dazu solltest Du dir vorher alle Konfigdateien deiner Installation sichern. Aber auch hier ist es wieder eher die persönliche Vorliebe.
Auf dem Suse 7.0 läuft z.B. Sendmail/Fetch-,Procmail mit Mailgate (Virenscanner), Apache, PHP/mysql, Samba, Netatalk, Backupserver, NFS, WU-FTP, APC-UVS, Printserver etc.
Der Grund, warum ich updaten will ist eigentlich nur der, dass ich mit selbst kompilieren z.T. Noch sehr viel Probleme habe. Und ich Angst habe,dass ich meine Konfiguration nicht mehr hinkriege ;-))
Mein Tip: lass es. SuSE 7.0 (mit den nötigen Patches und Updates) ist IMHO ein sehr stabiles System. 7.1 bringt zumindest mir nichts, was ich dringen bräuchte. Wenn Dein System läuft und stabil ist: Warum ändern? SuSE wird auch in der nächsten Zeit noch Updates für die 7.0 herausbringen. Und auch vom Kernel 2.4 / XFree 4 kann man die Finger lassen, wenn man nicht zwingend darauf angewiesen ist. Hier läuft ein Kernel 2.2.19 mit XFreee 3.3.6 zu meiner vollen Zufriedenheit. Da ich geschäftlich damit mein Geld verdiene, habe ich auch eine 7.1 hier herumliegen. Ich muß aber gestehen, daß ich die noch nicht einmal ausgepackt habe, da bei keiner produktiven Installation (6.4 / 7.0) ein Anlass zum Releasewechsel bestand. Wenn Du unbedingt mit der neuen Version rumspielen willst (oder aber ein bischen mit Compiler/Installation) würde ich an Deiner Stelle die Finger vom produktiven System lassen und entweder auf einer alten Möhre mal die neue Version ausprobieren oder zumindest in einer zweiten Partition. Andreas
On 31 May 2001, at 9:43, Ulli Kuhnle wrote:
Hi Andreas,
Bei mir hat der Update von 6.4 auf 7.0 (fast) problemlos funktioniert. Andere allerdinges haben hier von Schwierigkeiten berichtet.
zwischen 7.0 und 7.1 hat sich Schwerwiegenderes geändert (Pfade etc.).
Hallo Ulli, sorry, aber was ist daran schwerwiegend? Ja, der Standard-Pfad für die Run-Level Skripte hat sich geändert. Na und? Das ist doch kein Problem. Die Art und Weise, wie Skripte in den Runleveln automatisch sortiert werden, ist neu. Na und? Wo ist hier das Problem? Die glibc ist in einer neuen Version da. Und? Brauchst Du die neue Version unbedingt? Außerdem bringt jedes neue Release von vielen Programmen eine aktuellere Version mit (was nicht immer gut ist!). Ich weiß von keiner echten schwerwiegenden Änderung. Dazu würde ich etwas zählen, was beim Update dazu führt, daß der Update so nicht geht. Auch Kernel 2.4 oder Xfree 4 geht auf einer alten Version. Wie man hier in der Liste durch mitlesen erfährt, haben das auch viele gemacht. Und o wunder: Es läuft! In der Vergangenheit hatte sich auch der Pfad zu Dokumentation geändert. Sind das für Dich schon Probleme? Dann hast Du allerdings recht. Bei jeder (!) neuen Version ist was geändert. Sonst bräuchtest Du keine neue Version. Vielleicht habe ich es hier ein wenig überspitzt formuliert, aber ich stehe immer noch zu der Aussage: Jemand, der nur die SuSE Pakete (evtl. inklusive Updates) eingespielt hat kann von einer Version auf die nächste relativ problemlos umstellen wenn man ein paar Regeln beachtet: a) Kernel, falls selber kompiliert, wieder kompilieren b) eigene Module (ALSA, vmware etc) ggf. neu kompilieren c) geänderte Konfigdateien checken Es geht nicht ohne Prüfung, aber das erwarte ich zumindest nicht. Und ein Problem ist es auch nicht. Schwieriger wird es evtl. wenn man viel Software als tgz installiert hatte und nun SuSE das ganze per rpm einspielt. Das würde ich nicht tun. Aber jemand, der selbel tgz's installiert sollte das wissen. Andreas (der sich noch 'ne Stunde oder länger auslassen könnte, nu aber wieder was tun muss)
On 31-May-2001 Andreas Kyek wrote:
On 31 May 2001, at 9:43, Ulli Kuhnle wrote:
Bei mir hat der Update von 6.4 auf 7.0 (fast) problemlos funktioniert. Andere allerdinges haben hier von Schwierigkeiten berichtet.
zwischen 7.0 und 7.1 hat sich Schwerwiegenderes geändert (Pfade etc.). sorry, aber was ist daran schwerwiegend? Ja, der Standard-Pfad für die Run-Level Skripte hat sich geändert. Na und? Das ist doch kein Problem. Die Art und Weise, wie Skripte in den Runleveln automatisch sortiert werden, ist neu. Na und? Wo ist hier das Problem?
Du solltest nicht die urspruengliche Fragestellung bzw. den
Fragesteller aus den Augen verlieren. Er sprach eben gerade davon, dass
er sich vor den entsprechenden Nacharbeiten scheut. Heute erledige ich
so etwa auch mal schnell zwischendurch, aber in meinen
Linux-Anfangszeiten trieb mir das auch immer leicht den Schweiss auf
die Stirn.
Gruss,
Heinz.
--
E-Mail: Heinz W. Pahlke
On 31 May 2001, at 11:42, Heinz W. Pahlke wrote: [...]
Du solltest nicht die urspruengliche Fragestellung bzw. den Fragesteller aus den Augen verlieren. Er sprach eben gerade davon, dass er sich vor den entsprechenden Nacharbeiten scheut. Heute erledige ich so etwa auch mal schnell zwischendurch, aber in meinen Linux-Anfangszeiten trieb mir das auch immer leicht den Schweiss auf die Stirn.
Du hast Recht, was den ursprünglichen Fragesteller anging. Dem hatte ich ja auch schon geantwortet. Hoffentlich ausführlich genug. Meine jetzige Antwort bezog sich eigentlich mehr darauf, daß ich qualitativ keinen Unterschied zwischen einem Update 6.4 - 7.0 und 7.0 - 7.1 erkennen kann. Beides kann gehen oder schiefgehen und beides erfordert Nacharbeit. Aber vielleicht ist es wirklich schon so weit, das ich das einfach nicht mehr erkenne, weil ich zumindest meistens keine Anfangsprobleme mehr habe. Aber dieser Thread fängt wie so viele andere auch an, vom eigentlichen ursprünglichen Thema weg zu anderen (vielleicht auch interessanten) Themen hin zu driften. Das scheint ein systemimmanentes Problem zu sein. Und tschüss Andreas
On 31-May-2001 Andreas Kyek wrote:
Meine jetzige Antwort bezog sich eigentlich mehr darauf, daß ich qualitativ keinen Unterschied zwischen einem Update 6.4 - 7.0 und 7.0 - 7.1 erkennen kann. Beides kann gehen oder schiefgehen und beides erfordert Nacharbeit.
ACK.
Aber vielleicht ist es wirklich schon so weit, das ich das einfach nicht mehr erkenne, weil ich zumindest meistens keine Anfangsprobleme mehr habe.
Mir fiel das auch bloss alles so frisch ein, weil ich mich gerade fast einen kompletten Tag mit dem Updatre von der 7.0 auf die 7.1 rumgeschlagen habe. Was aber meine eigene Dussligkeit. Anstatt das Pferd von vorne aufzuzaeumen und als erstes wieder postfix zum Laufen zu bringen, um die Updatemeldungen von Yast empfangen zu koennen, habe ich es vom Schwanz her versucht (und geschafft :-)
Aber dieser Thread fängt wie so viele andere auch an, vom eigentlichen ursprünglichen Thema weg zu anderen (vielleicht auch interessanten) Themen hin zu driften.
Das scheint ein systemimmanentes Problem zu sein.
Klar, wir Linuxer sind eben ein kreatives Voelkchen ;-)
Beste Gruesse,
Heinz.
--
E-Mail: Heinz W. Pahlke
Andreas Kyek wrote:
On 31 May 2001, at 9:43, Ulli Kuhnle wrote:
Hi Andreas,
Bei mir hat der Update von 6.4 auf 7.0 (fast) problemlos funktioniert. Andere allerdinges haben hier von Schwierigkeiten berichtet.
zwischen 7.0 und 7.1 hat sich Schwerwiegenderes geändert (Pfade etc.).
Hallo Ulli,
sorry, aber was ist daran schwerwiegend? Ja, der Standard-Pfad für die Run-Level Skripte hat sich geändert. Na und? Das ist doch kein Problem. Die Art und Weise, wie Skripte in den Runleveln automatisch sortiert werden, ist neu. Na und? Wo ist hier das Problem?
Probleme entstehen dann, wenn Pakete, die Runlevel-Scripte verwenden und nicht von SuSE stammen, eingespielt wurden oder wenn Änderungen an Runlevel-Scripten vorgenommen wurden. Dürfte bei den meisten Usern also kaum Konsequenzen haben.
Die glibc ist in einer neuen Version da. Und? Brauchst Du die neue Version unbedingt? ACK, unbedingt braucht sie ein "Home-Desktop-User" kaum. Usern, deren Maschinen im Netz hängen, würde ich diesen Update aus Sicherheitsgründen allerdings empfehlen.
Außerdem bringt jedes neue Release von vielen Programmen eine aktuellere Version mit (was nicht immer gut ist!).
Ich weiß von keiner echten schwerwiegenden Änderung. Eine weitere, unter Umständen "wirkungsvolle" Änderung ist die Namensänderung der Pakete. SuSE verwendet jetzt lange Paketnamen. Das führt an einigen Stellen zu unter Umständen verwirrenden Problemen, insb. dann wenn man eigene RPMs erstellt hat (Paketabhängigkeiten). SuSE hat zwar versucht, ihre RPMs kompatibel zu gestalten, doch ganz gelungen ist das leider nicht. Auch das dürfte bei den weitaus meisten Usern allerdings kaum Probleme bereiten.
Dazu würde ich etwas zählen, was beim Update dazu führt, daß der Update so nicht geht. Auch Kernel 2.4 oder Xfree 4 geht auf einer alten Version. Wie man hier in der Liste durch mitlesen erfährt, haben das auch viele gemacht. Und o wunder: Es läuft!
In der Vergangenheit hatte sich auch der Pfad zu Dokumentation geändert. Sind das für Dich schon Probleme? Dann hast Du allerdings recht. Diese Änderungen (/usr/share/doc, /usr/share/man, /usr/share/info) sind wirklich nicht so ohne, wie sie auf Anhieb erscheinen mögen, da zahlreiche Programme diese Pfade hart codiert mit sich führen (U.a. manche man-/info-Browser/Viewer, User-Environments, viele rpm.specs, Apache-config). Solange man nur SuSE-Pakete installiert hat, sollte sich das allerdings nicht auswirken (Bei der Apache-config wirkt es sich allerdings aus). Bei Paketen aus anderen Quellen wird es u.U. schwierig.
Bei jeder (!) neuen Version ist was geändert. Sonst bräuchtest Du keine neue Version.
Vielleicht habe ich es hier ein wenig überspitzt formuliert, aber ich stehe immer noch zu der Aussage:
Jemand, der nur die SuSE Pakete (evtl. inklusive Updates) eingespielt hat kann von einer Version auf die nächste relativ problemlos umstellen wenn man ein paar Regeln beachtet: a) Kernel, falls selber kompiliert, wieder kompilieren b) eigene Module (ALSA, vmware etc) ggf. neu kompilieren c) geänderte Konfigdateien checken ACK, doch man beachte das "relativ" und "nur SuSE".
Es geht nicht ohne Prüfung, aber das erwarte ich zumindest nicht. Und ein Problem ist es auch nicht. ACK, in der Summe muss ich Dir voll und ganz zustimmen.
Ralf
Hallo, On 30-May-2001 Fabian Hüsser wrote:
Es geht um rpm und allgemeine Updates. Mir wurde mal geraten, dass wenn ich ein Update von irgenden einem Programm mache, dass ich dann die alte Version zuerst deinstallieren soll.
Irgendwie möchte ich das nicht schlucken. Ist das wirklich so ?
Ich kann nur sagen, wie ich es mache. In der Regel installiere ich einfach drueber, solange ich ein rpm-Paket durch ein anderes rpm-Paket bzw. ein tar.gz-Paket durch ein anderes tar.gz-Paket ersetze/update. Will ich ein tar.gz-Paket durch ein rpm-Paket (oder auch umgekehrt) ersetzen, versuche ich dagegen das vorherige Paket zu deinstallieren. Konfigurationsdateien sichere ich natuerlich vorher.
Und wie sieht das bei Programmen aus, die ich selber kompiliere ?
s.o., wobei das Deinstallieren aber etwas aufwendiger ist, wenn es kein make uninstall gibt. Ein erneutes make install zeigt dir aber, wohin die verschiedenen Programmbestandteile kopiert wurden, so dass ein manuelles Loeschen kein Problem ist. Ansonsten gibt es aber auch Hilfsprogramme, die dir letzteres abnehmen koennen. Bloss habe ich die noch nie ausprobiert, kann darueber also nichts weiter sagen.
musste mir das mit viel, sehr viel lesen aneignen. Nun möche ich auf Suse 7.1 bzw. 7.2 updaten. Nun habe ich aber gelesen, dass Suse da einige Pfade geändert hat und ich muss zugeben, dass ich z.B. unfähig bin irgendwelche Dinger in den richtigen Runlevel zu kopieren. Damit habe ich (noch) null Durchsicht.
Kurz: Würde so ein Update klappen ?
Nein. Ohne nachtraegliche Handarbeit hat bei mir noch kein Update geklappt.
Der Grund, warum ich updaten will ist eigentlich nur der, dass ich mit selbst kompilieren z.T. Noch sehr viel Probleme habe. Und ich Angst habe, dass ich meine Konfiguration nicht mehr hinkriege ;-))
Gegen letzteres hilft dir ein Backup.
Doch was ist am selber kompilieren so schwer? Wenn du nicht gerade ein
Paket erwischt, das schlecht oder gar nicht dokumentiert ist, brauchst
du nur nach den Erklaerungen in der README oder INSTALL vorgehen, die
eigentlich jedem tar.gz-Paket beiliegen sollten. Mit ./configure, make,
make install solltest du ansonsten fast immer richtig liegen.
Und dann gibt es ja noch immer die Liste. Ich habe hier jedenfalls fast
immer Hilfe erhalten.
Beste Gruesse,
Heinz.
--
E-Mail: Heinz W. Pahlke
participants (5)
-
Andreas Kyek -
Fabian Hüsser -
Heinz W. Pahlke -
Ralf Corsepius -
Ulli Kuhnle