Re: Newbie und Programminstallation, Mülldateien
Hallo Liste, jetzt bin ich nochmal mit ner Frage zum Installieren von Programmen da: Man findet ja im Netz so einige rpm's, die großteils für ältere Linuxversionen sind! Kann ich die auf ner neuen Version (z.B.8.0) ebenso (ohne Bedenken) installieren oder kann (bzw. kommt) es da zu Konflikten kommen? Kann man da eine generelle Auskunft geben oder muss man da probieren? Oder gibt es da Versionen die generell miteinander können und andere wieder nicht? Da werden dann ja immer mehr die typischen Windows Probleme sichtbar (auf der Version läufts, auf der anderen wieder nicht)! (Zerreisst mich jetzt nicht wegen der Aussage, wenn ich mich irre berichtigt mich aber bitte!) Mit der Ausnahme dass man sich halt meist mit den Src. selbst helfen kann! Vielen Dank für eure Infos Mit freundlichen Grüßen Mike
* Am 27.Aug.2002 postete Michael Messner:
Kann ich die auf ner neuen Version (z.B.8.0) ebenso (ohne Bedenken) installieren oder kann (bzw. kommt) es da zu Konflikten kommen?
Es könnte zu Konflikten kommen, wenn Du versuchst ältere Libs zu installieren.
Kann man da eine generelle Auskunft geben oder muss man da probieren?
Bei Programme sehe ich IMHO keine Gefahr. Denn, Programme fordern meistens das z.B. die libxyz z.B. in der Version >=0.12 da sein muss und du die Version 0.20 installiert hast. IMHO sollte die Lib dann auch abwärtskompatibel sein. Wenn rpm aber unbedingt die Version 0.12 von der libxyz haben möchte, aber Du die version 0.20 hast, würde ich vorsichtig sein. Ich habe da schon meine böse Überraschung erlebt.
Oder gibt es da Versionen die generell miteinander können und andere wieder nicht?
Könnte passieren. Bye Michael -- K: Können Sie mir ein gutes Grafik-Adventure empfehlen ? V: Jo... wir hätten WINDOWS da... _______________________________________________________________________ Registered Linux User #228306 http://macbyte.info/ ICQ #151172379
Hallo, On 27-Aug-2002 Michael Raab wrote:
* Am 27.Aug.2002 postete Michael Messner:
Kann ich die auf ner neuen Version (z.B.8.0) ebenso (ohne Bedenken) installieren oder kann (bzw. kommt) es da zu Konflikten kommen?
Es könnte zu Konflikten kommen, wenn Du versuchst ältere Libs zu installieren.
Aber da rpm einem ja sagt, dass es Konflikte gibt, und die Installation dann beendet, ist das Risiko gering. Anders sieht es aus, wenn man mit rpm --force installiert, aber das sollte man wirklich nur tun, wenn man weiss, was man tut.
Bei Programme sehe ich IMHO keine Gefahr. Denn, Programme fordern meistens das z.B. die libxyz z.B. in der Version >=0.12 da sein muss und du die Version 0.20 installiert hast. IMHO sollte die Lib dann auch abwärtskompatibel sein.
Wenn rpm aber unbedingt die Version 0.12 von der libxyz haben möchte, aber Du die version 0.20 hast, würde ich vorsichtig sein. Ich habe da schon meine böse Überraschung erlebt.
Wenn es sich um ein erstmalig installiertes Programm handelt, kann man es mit rpm --nodeps versuchen, einfach entsprechende Links legen. Manche Programme wollen einfach bestimmte lib-Versionen, obwohl sie auch mit neueren koennten. Wenn es nicht klappt, kann man sich immer noch ueberlegen, ob es ein rpm -e oder ein Update der entsprechenden lib bringen soll. Wenn es sich um ein Programm-Update handelt, waere ich aber vorsichtiger. Immerhin ueberschreibt man sich ja dann mit --nodeps seine alte Version. Wenn es mit den Links doch nicht klappt, muss man eben auch noch die lib updaten oder wieder die aeltere Programmversion aufspielen.
Oder gibt es da Versionen die generell miteinander können und andere wieder nicht?
Bei den Tausenden von Programmen und noch mehr Programmversionen, die es gibt, duerfte eine generelle Aussage schwierig sein. Beste Gruesse, Heinz. -- http://www.pahlke-online.de/reisenews/ http://www.Pahlke-KunstWebDesign.de/
* Am 27.Aug.2002 postete Heinz W. Pahlke:
Hallo,
On 27-Aug-2002 Michael Raab wrote:
* Am 27.Aug.2002 postete Michael Messner:
Kann ich die auf ner neuen Version (z.B.8.0) ebenso (ohne Bedenken) installieren oder kann (bzw. kommt) es da zu Konflikten kommen?
Es könnte zu Konflikten kommen, wenn Du versuchst ältere Libs zu installieren.
Aber da rpm einem ja sagt, dass es Konflikte gibt, und die Installation dann beendet, ist das Risiko gering. Anders sieht es aus, wenn man mit rpm --force installiert, aber das sollte man wirklich nur tun, wenn man weiss, was man tut.
ACK.
Bei Programme sehe ich IMHO keine Gefahr. Denn, Programme fordern meistens das z.B. die libxyz z.B. in der Version >=0.12 da sein muss und du die Version 0.20 installiert hast. IMHO sollte die Lib dann auch abwärtskompatibel sein.
Wenn rpm aber unbedingt die Version 0.12 von der libxyz haben möchte, aber Du die version 0.20 hast, würde ich vorsichtig sein. Ich habe da schon meine böse Überraschung erlebt.
Wenn es sich um ein erstmalig installiertes Programm handelt, kann man es mit rpm --nodeps versuchen, einfach entsprechende Links legen. Manche Programme wollen einfach bestimmte lib-Versionen, obwohl sie auch mit neueren koennte.
Das könnte auch eine Strategie der Distrubititionen sein um den Anwender zu verunsichern, mit dem Ziel, das sich der Anwender sich die neuste Version der Distri kauft. Bye Michael -- Liebe ist Tollheit. Sie überspringt einen Bach, wo es eine Brücke gibt! _______________________________________________________________________ Registered Linux User #228306 http://macbyte.info/ ICQ #151172379
Hallo, On 27-Aug-2002 Michael Raab wrote:
* Am 27.Aug.2002 postete Heinz W. Pahlke:
Wenn es sich um ein erstmalig installiertes Programm handelt, kann man es mit rpm --nodeps versuchen, einfach entsprechende Links legen. Manche Programme wollen einfach bestimmte lib-Versionen, obwohl sie auch mit neueren koennte.
Das könnte auch eine Strategie der Distrubititionen sein um den Anwender zu verunsichern, mit dem Ziel, das sich der Anwender sich die neuste Version der Distri kauft.
Ich denke, dass liegt wohl eher an den Programmautoren. Die Distributoren stellen ja nur noch alles zusammen. Beste Gruesse, Heinz. -- http://www.pahlke-online.de/reisenews/ http://www.Pahlke-KunstWebDesign.de/
* Am 27.Aug.2002 postete Heinz W. Pahlke:
On 27-Aug-2002 Michael Raab wrote:
* Am 27.Aug.2002 postete Heinz W. Pahlke:
Wenn es sich um ein erstmalig installiertes Programm handelt, kann man es mit rpm --nodeps versuchen, einfach entsprechende Links legen. Manche Programme wollen einfach bestimmte lib-Versionen, obwohl sie auch mit neueren koennte.
Das könnte auch eine Strategie der Distrubititionen sein um den Anwender zu verunsichern, mit dem Ziel, das sich der Anwender sich die neuste Version der Distri kauft.
Ich denke, dass liegt wohl eher an den Programmautoren. Die Distributoren stellen ja nur noch alles zusammen.
Das ist richtig. Aber werden die Abhängigkeiten nicht bei rpm festgelegt? Bye Michael -- Nein, GIF heisst nicht "Girls in Files". _______________________________________________________________________ Registered Linux User #228306 http://macbyte.info/ ICQ #151172379
On 27-Aug-2002 Michael Raab wrote:
* Am 27.Aug.2002 postete Heinz W. Pahlke:
Ich denke, dass liegt wohl eher an den Programmautoren. Die Distributoren stellen ja nur noch alles zusammen.
Das ist richtig. Aber werden die Abhängigkeiten nicht bei rpm festgelegt?
Weiss ich jetzt ehrlich gesagt nicht genau, aber wenn das beim Bauen der Packages grundsaetzlich immer manuell geprueft werden muss, waere das jedenfalls ein enormer Aufwand. Aber wir haben ja hier in der Liste einige rpm-Fachleute. Vielleicht koennen die was dazu sagen. Ansonsten schau ich morgen mal in "Maximum rpm". Jetzt findet meine Frau, ich koennte mich ruhig mal vom Rechner abflanschen :-) Noch einen schoenen Abend, Heinz. -- http://www.pahlke-online.de/reisenews/ http://www.Pahlke-KunstWebDesign.de/
"Heinz W. Pahlke"
Das ist richtig. Aber werden die Abhängigkeiten nicht bei rpm festgelegt?
Ja und nein ;-) Du kannst natürlich in Requires angeben, welche Bibliothek benötigt wird, aber das wäre Blödsinn. Wenn im Spec-File Autoreqprov: on steht (bei uns in allen Paketen), dann ermittelt rpm selber, was vom Paket benötigt bzw. zur Verfügung gestellt wird. Das ist deutlich besser, weil dann keine hartkodierte Abhängigkeit zwischen Paketen vorliegt. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
Am Dienstag, 27. August 2002 18:06 schrieb Michael Raab:
Das ist richtig. Aber werden die Abhängigkeiten nicht bei rpm festgelegt?
Nicht unbedingt, man kann im SPEC-File festlegen, von welchen RPM's das gebaute abhängt, die Angabe muß allerdings nicht eingegeben werden, dann untersucht rpm die Dateien im Paket, welche Bibliotheken von diesen eingebunden werden und baut die abhängigkeiten von diesen Libs selbst. Letzteres ist dann eben vom Programm abhängig, wenn diese libxyz.so.1 benötigt, sind die Abhängigkeiten entsprechend gesetzt und eben exakt diese lib verwendet. Wird flexibel libxyz.so eingebaut, ist die Version egal (was natürlich auch problematisch sein kann, wenn unterschiedliche lib-Versionen nicht kompatibel sind). -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de
Hallo zusammen, ich habe gerade versucht die SCSI-Emulation für den CD-Brenner unter SuSE-8.1 aktivieren. Wie unter 8.0 bin ich hierzu gemäss der Anleitung von SuSE (Supportdatenbank) vorgegangen. Mittels Yast die Append-Zeile hdd-ide-scsi hinzugefügt. Der Brenner hängt am sekundären Kanal und ist als Slave gejumpert. Der Brenner lässt sich auch unter hdd mounten. Weiter habe ich gemäss der o.g. Anleitung die Zeile /sbin/modprobe ide-scsi angefügt. Nach dem booten kann ich den Brenner immernoch unter hdd mounten und nicht unter scd0 ansprechen. Hat sich bei 8.1 etwas geändert oder wie kann ich die SCSI-Emulation laden? Gruss Pixel
Sven Gehr schrieb:
Hallo zusammen,
ich habe gerade versucht die SCSI-Emulation für den CD-Brenner unter SuSE-8.1 aktivieren. Wie unter 8.0 bin ich hierzu gemäss der Anleitung von SuSE (Supportdatenbank) vorgegangen. Mittels Yast die Append-Zeile hdd-ide-scsi hinzugefügt. Der Brenner hängt am sekundären Kanal und ist als Slave gejumpert. Der Brenner lässt sich auch unter hdd mounten. Weiter habe ich gemäss der o.g. Anleitung die Zeile /sbin/modprobe ide-scsi angefügt. Nach dem booten kann ich den Brenner immernoch unter hdd mounten und nicht unter scd0 ansprechen. Hat sich bei 8.1 etwas geändert oder wie kann ich die SCSI-Emulation laden?
Gruss Pixel
Hallo Sven, das Thema ging erst vor wenigen durch die Liste. Schau Dir doch bitte mal den Thread unter folgendem Link an: http://lists.suse.com/archive/suse-linux/2002-Sep/4564.html Wenn das alles nicht hilft, dann frag doch einfach noch mal. ;-) Gruss Pascal PS: Ich weiss nicht, ob Dein Bildschirm 400 Zeichen in einer Zeile darstellen kann, meiner kann's nicht, deshalb faende ich es nett, wenn Du nach so etwa 68 Zeichen einmal auf [Return] druecken wuerdest. _DANKE_! -- "SuSE woody" / die "hoelzerne" SuSE http://www.edelhost.de/linux/suse_7.3/other/woody.html _______________________________________________ / \ | Dieses Schreiben wurde maschinell erstellt, | | es traegt daher weder Unterschrift noch Siegel | | [ reg. Linux user #231277 ] | \_______________________________________________/
Hallo, also ich habe den kompletten Thread gelesen jedoch komme ich nicht weiter. Wie gesagt. Ich habe gemäss Anleitung die Append-Zeile mit Yast eingefügt. Mein Brenner ist hdd. Das stimmt definitiv da ich ihn darunter ansprechen kann. Den Eintrag in der /etc/init.d/boot.local habe ich gepostet. Zuvor habe ich "modprobe ide-scsi" in der Konsole getestet -> ok ABER es funktioniert nicht. Ich bekomme die gleiche Fehlermeldung wie in dem vorausgegangen Thread gepostet. ...not a ... block .... Da ich nach dem erneuten booten das LW immer noch unter hdd mounten kann kann es ja nicht an einem falschen Link im /dev liegen. Unter SuSE-7.3 + 8.0 habe ich das immer so gemacht und es hat immer geklappt. Was läuft falsch? Gruss Sven P.S. Habe die Zeilenbreite beschränkt. Hoffe es passt jetzt ;-) Am Donnerstag, 3. Oktober 2002 00:01 schrieb Pascal Volk:
Sven Gehr schrieb:
Hallo zusammen,
ich habe gerade versucht die SCSI-Emulation für den CD-Brenner unter SuSE-8.1 aktivieren. Wie unter 8.0 bin ich hierzu gemäss der Anleitung von SuSE (Supportdatenbank) vorgegangen. Mittels Yast die Append-Zeile hdd-ide-scsi hinzugefügt. Der Brenner hängt am sekundären Kanal und ist als Slave gejumpert. Der Brenner lässt sich auch unter hdd mounten. Weiter habe ich gemäss der o.g. Anleitung die Zeile /sbin/modprobe ide-scsi angefügt. Nach dem booten kann ich den Brenner immernoch unter hdd mounten und nicht unter scd0 ansprechen. Hat sich bei 8.1 etwas geändert oder wie kann ich die SCSI-Emulation laden?
Gruss Pixel
Hallo Sven,
das Thema ging erst vor wenigen durch die Liste. Schau Dir doch bitte mal den Thread unter folgendem Link an: http://lists.suse.com/archive/suse-linux/2002-Sep/4564.html
Wenn das alles nicht hilft, dann frag doch einfach noch mal. ;-)
Gruss Pascal
PS: Ich weiss nicht, ob Dein Bildschirm 400 Zeichen in einer Zeile darstellen kann, meiner kann's nicht, deshalb faende ich es nett, wenn Du nach so etwa 68 Zeichen einmal auf [Return] druecken wuerdest. _DANKE_!
Hi Sven Sven Gehr schrieb:
Hallo,
also ich habe den kompletten Thread gelesen jedoch komme ich nicht weiter. Wie gesagt. Ich habe gemäss Anleitung die Append-Zeile mit Yast eingefügt. Mein Brenner ist hdd. Das stimmt definitiv da ich ihn darunter ansprechen kann. Den Eintrag in der /etc/init.d/boot.local habe ich gepostet. Zuvor habe ich "modprobe ide-scsi" in der Konsole getestet -> ok
Ganz langsam, es ist schon spaet. ;-) Welchen Beitrag aus der SDB hast Du gelesen? Nicht den hier: http://sdb.suse.de/de/sdb/html/81_ide-scsi.html (Kann inhaltlich nicht ganz hinhauen!) Was hast Du bitte mit der /etc/init.d/boot.local gemacht. Kann ich nicht ganz nachvollziehen, da ich die 7.3 habe.
ABER es funktioniert nicht. Ich bekomme die gleiche Fehlermeldung wie in dem vorausgegangen Thread gepostet. ...not a ... block ....
Da ich nach dem erneuten booten das LW immer noch unter hdd mounten kann kann es ja nicht an einem falschen Link im /dev liegen.
Genau das wir es sein. Was sagt denn "dir /dev/cdr*" --- faxe@EL-PRESIDENTE:~> dir /dev/cdr* lrwxrwxrwx 1 root root 8 Sep 26 07:41 cdrecorder -> /dev/sr1 lrwxrwxrwx 1 root root 8 Sep 26 07:42 cdrom -> /dev/sr1 faxe@EL-PRESIDENTE:~> --- Falls es einen Link auf /dev/hdd gibt, muesste das Problem gefunden sein und durch Anpassung des Links behoben werden.
Unter SuSE-7.3 + 8.0 habe ich das immer so gemacht und es hat immer geklappt. Was läuft falsch?
Gruss Sven
P.S. Habe die Zeilenbreite beschränkt. Hoffe es passt jetzt ;-)
Das mit dem Umbruch passt jetzt gar wunderbar. :-D Dafuer hast Du jetzt TOFU produziert. -> http://learn.to/quote Versuche (pruefe) doch mal bitte folgendes: * ide-scsi in /etc/sysconfig/kernel einfuegen * mk_initrd * in der append-Zeile von lilo hdd=ide-scsi einfuegen * lilo -v aufrufen * link in /dev/cdrom und /dev/cdrecorder anpassen -> /dev/sr0 * shutdown -r now * abwarten bis der Rechner wieder da ist * cdrecord -scanbus Klappt das??? Gruss Pascal -- "SuSE woody" / die "hoelzerne" SuSE http://www.edelhost.de/linux/suse_7.3/other/woody.html _______________________________________________ / \ | Dieses Schreiben wurde maschinell erstellt, | | es traegt daher weder Unterschrift noch Siegel | | [ reg. Linux user #231277 ] | \_______________________________________________/
Hallo Liste, ich denke ich habe das Problem gefunden. Bei der Neuinstallation von SuSE-8.1 wird Grub nicht Lilo installiert. Die beschriebene Vorgehnsweise funktioniert bei Grub nicht. Gruss Sven Am Donnerstag, 3. Oktober 2002 01:35 schrieb Pascal Volk:
Hi Sven
Sven Gehr schrieb:
Hallo,
also ich habe den kompletten Thread gelesen jedoch komme ich nicht weiter. Wie gesagt. Ich habe gemäss Anleitung die Append-Zeile mit Yast eingefügt. Mein Brenner ist hdd. Das stimmt definitiv da ich ihn darunter ansprechen kann. Den Eintrag in der /etc/init.d/boot.local habe ich gepostet. Zuvor habe ich "modprobe ide-scsi" in der Konsole getestet -> ok
Ganz langsam, es ist schon spaet. ;-) Welchen Beitrag aus der SDB hast Du gelesen? Nicht den hier: http://sdb.suse.de/de/sdb/html/81_ide-scsi.html (Kann inhaltlich nicht ganz hinhauen!)
Was hast Du bitte mit der /etc/init.d/boot.local gemacht. Kann ich nicht ganz nachvollziehen, da ich die 7.3 habe.
ABER es funktioniert nicht. Ich bekomme die gleiche Fehlermeldung wie in dem vorausgegangen Thread gepostet. ...not a ... block ....
Da ich nach dem erneuten booten das LW immer noch unter hdd mounten kann kann es ja nicht an einem falschen Link im /dev liegen.
Genau das wir es sein. Was sagt denn "dir /dev/cdr*" --- faxe@EL-PRESIDENTE:~> dir /dev/cdr* lrwxrwxrwx 1 root root 8 Sep 26 07:41 cdrecorder -> /dev/sr1 lrwxrwxrwx 1 root root 8 Sep 26 07:42 cdrom -> /dev/sr1 faxe@EL-PRESIDENTE:~> ---
Falls es einen Link auf /dev/hdd gibt, muesste das Problem gefunden sein und durch Anpassung des Links behoben werden.
Unter SuSE-7.3 + 8.0 habe ich das immer so gemacht und es hat immer geklappt. Was läuft falsch?
Gruss Sven
P.S. Habe die Zeilenbreite beschränkt. Hoffe es passt jetzt ;-)
Das mit dem Umbruch passt jetzt gar wunderbar. :-D Dafuer hast Du jetzt TOFU produziert. -> http://learn.to/quote
Versuche (pruefe) doch mal bitte folgendes: * ide-scsi in /etc/sysconfig/kernel einfuegen * mk_initrd * in der append-Zeile von lilo hdd=ide-scsi einfuegen * lilo -v aufrufen * link in /dev/cdrom und /dev/cdrecorder anpassen -> /dev/sr0 * shutdown -r now * abwarten bis der Rechner wieder da ist * cdrecord -scanbus
Klappt das???
Gruss Pascal
* Michael Raab schrieb am 27.Aug.2002:
* Am 27.Aug.2002 postete Michael Messner:
Kann ich die auf ner neuen Version (z.B.8.0) ebenso (ohne Bedenken) installieren oder kann (bzw. kommt) es da zu Konflikten kommen?
Es könnte zu Konflikten kommen, wenn Du versuchst ältere Libs zu installieren.
Kann man da eine generelle Auskunft geben oder muss man da probieren?
Bei Programme sehe ich IMHO keine Gefahr. Denn, Programme fordern meistens das z.B. die libxyz z.B. in der Version >=0.12 da sein muss und du die Version 0.20 installiert hast. IMHO sollte die Lib dann auch abwärtskompatibel sein.
Wenn rpm aber unbedingt die Version 0.12 von der libxyz haben möchte, aber Du die version 0.20 hast, würde ich vorsichtig sein. Ich habe da schon meine böse Überraschung erlebt.
Da habe ich doch auch mal glatt eine Frage zu: Nur mal als Beispiel, es gibt unter vielen, vielen anderen: /usr/lib/libmenu.a /usr/lib/libmenu.so -> libmenu.so.5 /usr/lib/libmenu.so.4 -> libmenu.so.4.2 /usr/lib/libmenu.so.4.2 /usr/lib/libmenu.so.5 -> libmenu.so.5.2 /usr/lib/libmenu.so.5.2 Wenn ein Programm libmenu.so oder libmenu.so.5 verlangt, so wird libmenu.so.5.2 genommen, wenn es libmenu.so.4 verlangt, so wird libmenu.so.4.2 genommen. Richtig? Hört sich doch recht sinnvoll an, wo tauchen denn da Probleme auf? Wenn ein Programm explizit libmenu.so.5.1 verlangt, oder so? Aber gehört ein solches Programm nicht abgewatscht? Und was ist mit der statischen Bibliothek? Zu libmenu.a gibt es offensichtlich keine verschiedene Versionen? Kann man davon ausgehen, daß es mit libmenu.so.5.2 übereinstimmt? Wird ja nur beim Kompelieren benötigt. Wenn es einmal eingebunden ist, dann ist es ja da. Das hieße, daß libmenu.so.4 keinerlei Vorteile gegenüber libmenu.so.5 hat, es nur aus Kompatibilitätsgründen mitgeschleppt wird. Richtig? Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
* Am 27.Aug.2002 postete Bernd Brodesser:
* Michael Raab schrieb am 27.Aug.2002:
* Am 27.Aug.2002 postete Michael Messner:
Kann ich die auf ner neuen Version (z.B.8.0) ebenso (ohne Bedenken) installieren oder kann (bzw. kommt) es da zu Konflikten kommen?
Es könnte zu Konflikten kommen, wenn Du versuchst ältere Libs zu installieren.
Kann man da eine generelle Auskunft geben oder muss man da probieren?
Bei Programme sehe ich IMHO keine Gefahr. Denn, Programme fordern meistens das z.B. die libxyz z.B. in der Version >=0.12 da sein muss und du die Version 0.20 installiert hast. IMHO sollte die Lib dann auch abwärtskompatibel sein.
Wenn rpm aber unbedingt die Version 0.12 von der libxyz haben möchte, aber Du die version 0.20 hast, würde ich vorsichtig sein. Ich habe da schon meine böse Überraschung erlebt.
Da habe ich doch auch mal glatt eine Frage zu: Nur mal als Beispiel, es gibt unter vielen, vielen anderen:
[ ... libs ... ]
Wenn ein Programm libmenu.so oder libmenu.so.5 verlangt, so wird libmenu.so.5.2 genommen, wenn es libmenu.so.4 verlangt, so wird libmenu.so.4.2 genommen. Richtig?
Richtig.
Hört sich doch recht sinnvoll an, wo tauchen denn da Probleme auf?
Theoretisch dürften da keine Probleme auftauchen, solange die verlangte Funktion in der lib auch vorhanden ist.
Wenn ein Programm explizit libmenu.so.5.1 verlangt, oder so? Aber gehört ein solches Programm nicht abgewatscht?
Wenn Du mit abgewatscht abgeschossen meinst, hast Du Recht.
Und was ist mit der statischen Bibliothek? Zu libmenu.a gibt es offensichtlich keine verschiedene Versionen?
Sind in lib?????.a nicht die Einstiegsadressen für lib?????.so enthalten?
Kann man davon ausgehen, daß es mit libmenu.so.5.2 übereinstimmt?
Nicht unbedingt. Ein Update der glibc hatte mir mal irgendwie mein System versaut gehabt. Die Programme sind einfach abgeschmiert. Nach dem Downgrade der glibc lief wieder alles wie geschmiert.
Wird ja nur beim Kompelieren benötigt. Wenn es einmal eingebunden ist, dann ist es ja da.
Das hieße, daß libmenu.so.4 keinerlei Vorteile gegenüber libmenu.so.5 hat, es nur aus Kompatibilitätsgründen mitgeschleppt wird. Richtig?
Auch Richtig. Bye Michael -- _______________________________________________________________________ Registered Linux User #228306 http://macbyte.info/ ICQ #151172379
Am Mit, 2002-08-28 um 03.33 schrieb Michael Raab:
* Am 27.Aug.2002 postete Bernd Brodesser:
* Michael Raab schrieb am 27.Aug.2002:
* Am 27.Aug.2002 postete Michael Messner:
Und was ist mit der statischen Bibliothek? Zu libmenu.a gibt es offensichtlich keine verschiedene Versionen?
Sind in lib?????.a nicht die Einstiegsadressen für lib?????.so enthalten? Nein. libxxx.a ist die statischen Version von libxxx.
Wenn ein Programm damit gelinkt wird/wurde, besteht überhaupt keine Abhängigkeit des Programmes zu libxxx.so.*, da libxxx.a in das Programm eingebunden wird/wurde (etwas vereinfacht ausgedrückt: libxxx.a wird Bestandteil von "Programm") Ralf
* Michael Raab schrieb am 28.Aug.2002:
* Am 27.Aug.2002 postete Bernd Brodesser:
Und was ist mit der statischen Bibliothek? Zu libmenu.a gibt es offensichtlich keine verschiedene Versionen?
Sind in lib?????.a nicht die Einstiegsadressen für lib?????.so enthalten?
Nein. Dazu hat Ralf schon das nötige geschrieben.
Kann man davon ausgehen, daß es mit libmenu.so.5.2 übereinstimmt?
Nicht unbedingt. Ein Update der glibc hatte mir mal irgendwie mein System versaut gehabt. Die Programme sind einfach abgeschmiert. Nach dem Downgrade der glibc lief wieder alles wie geschmiert.
ich meinte libXXX.a mit libXXX.so.$MAXVERSION Dabei meinte ich nicht, daß die Binärdateien übereinstimmen, sondern die Quellen. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Hallo, On Wed, 28 Aug 2002, Bernd Brodesser wrote: [libmenu.a]
Kann man davon ausgehen, daß es mit libmenu.so.5.2 übereinstimmt? [..] ich meinte libXXX.a mit libXXX.so.$MAXVERSION
Dabei meinte ich nicht, daß die Binärdateien übereinstimmen, sondern die Quellen.
Da sollte ein 'rpm -qf' helfen, i.d.R. wird die lib*.a wohl die statische Version der aktuellen sein -- und das sollte IMO auch so sein. Prinzipiell waere's aber moeglich, dass das .a noch aus dem aelteren -devel stammt, da vom neuen das -devel (noch) nicht installiert wurde, das sollte man dann aber nachholen. -dnh -- Man tut was man kann. Kann amn aber wirklich immer das was man tut? [Woko° in dag°]
B.Brodesser@t-online.de (Bernd Brodesser) [27 Aug 2002 19:38:32]:
/usr/lib/libmenu.so -> libmenu.so.5 /usr/lib/libmenu.so.4 -> libmenu.so.4.2 /usr/lib/libmenu.so.4.2 /usr/lib/libmenu.so.5 -> libmenu.so.5.2 /usr/lib/libmenu.so.5.2
Wenn ein Programm libmenu.so oder libmenu.so.5 verlangt, so wird libmenu.so.5.2 genommen, wenn es libmenu.so.4 verlangt, so wird libmenu.so.4.2 genommen. Richtig? Hört sich doch recht sinnvoll an, wo tauchen denn da Probleme auf? Wenn ein Programm explizit libmenu.so.5.1 verlangt, oder so? Aber gehört ein solches Programm nicht abgewatscht?
Wenn eine dynamische Bibliothek erstellt wird, kann man dem Linker angeben, welchen internen Namen (der sog. Soname) die Bibliothek haben soll. In den allermeisten Fällen ist dies lib<name>.so.<Hauptversion>. Wird nun ein Programm gegen diese Bibliothek gelinkt, wird dieser Soname im Programm eingetragen. Wird dieses Programm ausgeführt, sucht der dynamische Linker nach einer Bibliothek mit diesem Namen. Über den Symlink libname.so.<hauptversion> -> libname.so.<hauptversion>.<minorversion> findet er sie dann auch. Die lib<name>.so Dateien werden i.d.R. ausschliesslich vom statischen Linker zum Erstellen des Programmes benötigt. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
* Philipp Thomas schrieb am 01.Sep.2002:
B.Brodesser@t-online.de (Bernd Brodesser) [27 Aug 2002 19:38:32]:
/usr/lib/libmenu.so -> libmenu.so.5 /usr/lib/libmenu.so.4 -> libmenu.so.4.2 /usr/lib/libmenu.so.4.2 /usr/lib/libmenu.so.5 -> libmenu.so.5.2 /usr/lib/libmenu.so.5.2
Wenn ein Programm libmenu.so oder libmenu.so.5 verlangt, so wird libmenu.so.5.2 genommen, wenn es libmenu.so.4 verlangt, so wird libmenu.so.4.2 genommen. Richtig? Hört sich doch recht sinnvoll an, wo tauchen denn da Probleme auf? Wenn ein Programm explizit libmenu.so.5.1 verlangt, oder so? Aber gehört ein solches Programm nicht abgewatscht?
Wenn eine dynamische Bibliothek erstellt wird, kann man dem Linker angeben, welchen internen Namen (der sog. Soname) die Bibliothek haben soll. In den allermeisten Fällen ist dies lib<name>.so.<Hauptversion>. Wird nun ein Programm gegen diese Bibliothek gelinkt, wird dieser Soname im Programm eingetragen. Wird dieses Programm ausgeführt, sucht der dynamische Linker nach einer Bibliothek mit diesem Namen. Über den Symlink libname.so.<hauptversion> -> libname.so.<hauptversion>.<minorversion> findet er sie dann auch.
Die Frage ist, was passiert, wenn ein Programm gegen libname.so.<hauptversion>.<minorversion> gelinkt ist, der Anwender aber libname.so.<hauptversion>.<andereminorversion> hat. Funktioniert es dann trotzdem? Und was ist, wenn er eine höhere hauptversion hat? Und was nimmt ./configure, wenn man selbst kompeliert?
Die lib<name>.so Dateien werden i.d.R. ausschliesslich vom statischen Linker zum Erstellen des Programmes benötigt.
Du meinst lib<name>.a so steht für shered object, a für archiv. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
B.Brodesser@t-online.de (Bernd Brodesser) [1 Sep 2002 11:24:33 +0200]:
Die Frage ist, was passiert, wenn ein Programm gegen libname.so.<hauptversion>.<minorversion> gelinkt ist, der Anwender aber libname.so.<hauptversion>.<andereminorversion> hat.
Das Programm wird nicht laufen, da die Abhängigkeit nicht erfüllt ist. Aber die einzigen Bibliotheken, die ich kenne und deren Soname die volle Version besitzt sind die zu den binutils gehörenden Bibliotheken (libbfd, lipopcodes).
Und was ist, wenn er eine höhere hauptversion hat?
Auch dann funktioniert es nicht und das ist gut so! Eben weil dem so ist, können Programme koexistieren, die unterschiedliche Versionen der gleichen Bibliothek verwenden.
Und was nimmt ./configure, wenn man selbst kompiliert?
Die Bibliothek, auf die lib<name>.so verweist.
Die lib<name>.so Dateien werden i.d.R. ausschliesslich vom statischen Linker zum Erstellen des Programmes benötigt.
Du meinst lib<name>.a so steht für shared object, a für archiv.
Nein, ich meinte durchaus lib<name>.so. Beachte, dass ich vom statischen Linker, also dem normalen ld und nicht vom statischen Linken sprach. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
Hallo Philipp, * Philipp Thomas schrieb am 02.Sep.2002:
B.Brodesser@t-online.de (Bernd Brodesser) [1 Sep 2002 11:24:33 +0200]:
Die Frage ist, was passiert, wenn ein Programm gegen libname.so.<hauptversion>.<minorversion> gelinkt ist, der Anwender aber libname.so.<hauptversion>.<andereminorversion> hat.
Das Programm wird nicht laufen, da die Abhängigkeit nicht erfüllt ist. Aber die einzigen Bibliotheken, die ich kenne und deren Soname die volle Version besitzt sind die zu den binutils gehörenden Bibliotheken (libbfd, lipopcodes).
Da haben wir anscheinend aneinander vorbeigeredet. Angenommen ein Programm ist auf libname.so.<hauptversion> gelinkt und libname.so.<hauptversion> ist ein SymLink (Oh, oh, hier hat das Wort link eine vollkommen andere Bedeutung) auf libname.so.<hauptversion>.<minorversion>. Ich installiere mir dieses Programm und ich habe auch libname.so.<hauptversion> bei mir ist es aber ein Symlink auf libname.so.<hauptversion>.<neuereminorversion> Wenn das Programm dann bei mir nicht läuft, dann könnte man sich das mit major- und minorversion auch schenken und nur eine Versionsnummer verteilen.
Und was ist, wenn er eine höhere hauptversion hat?
Auch dann funktioniert es nicht und das ist gut so! Eben weil dem so ist, können Programme koexistieren, die unterschiedliche Versionen der gleichen Bibliothek verwenden.
Wieso? Wenn alles auch mit der neusten Version liefe, dann gäb es doch auch keine Probleme.
Und was nimmt ./configure, wenn man selbst kompiliert?
Die Bibliothek, auf die lib<name>.so verweist.
Gut.
Die lib<name>.so Dateien werden i.d.R. ausschliesslich vom statischen Linker zum Erstellen des Programmes benötigt.
Du meinst lib<name>.a so steht für shared object, a für archiv.
Nein, ich meinte durchaus lib<name>.so. Beachte, dass ich vom statischen Linker, also dem normalen ld und nicht vom statischen Linken sprach.
Huch, ich kenne nur den ld. Was ist denn ein dynamischer Linker? Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Am Mon, 2002-09-02 um 09.31 schrieb Bernd Brodesser:
Hallo Philipp,
* Philipp Thomas schrieb am 02.Sep.2002:
B.Brodesser@t-online.de (Bernd Brodesser) [1 Sep 2002 11:24:33 +0200]:
Die Frage ist, was passiert, wenn ein Programm gegen libname.so.<hauptversion>.<minorversion> gelinkt ist, der Anwender aber libname.so.<hauptversion>.<andereminorversion> hat.
Das Programm wird nicht laufen, da die Abhängigkeit nicht erfüllt ist. Aber die einzigen Bibliotheken, die ich kenne und deren Soname die volle Version besitzt sind die zu den binutils gehörenden Bibliotheken (libbfd, lipopcodes).
Da haben wir anscheinend aneinander vorbeigeredet. Angenommen ein Programm ist auf libname.so.<hauptversion> gelinkt und libname.so.<hauptversion> ist ein SymLink (Oh, oh, hier hat das Wort link eine vollkommen andere Bedeutung) auf libname.so.<hauptversion>.<minorversion>. Ich installiere mir dieses Programm und ich habe auch libname.so.<hauptversion> bei mir ist es aber ein Symlink auf libname.so.<hauptversion>.<neuereminorversion>
Die Versionierung einer Library deren Nutzung durch ein Programm das von Dir beschriebene Verhalten zeigt ist defekt, da per Definition alle libxxx.X.Y und libxxx.X.(Y+n) (mit n >= 0) binär-kompatibel seien _müssen_.
Wenn das Programm dann bei mir nicht läuft, dann könnte man sich das mit major- und minorversion auch schenken und nur eine Versionsnummer verteilen. Richtig.
Nur, ist es genau Sinn und Zweck der minor-Versionnumber genau dieses Problem zu umgehen, da Programme normalerweise libxxx.X verlangen, und es ihnen egal sein sollte, ob nun libxxx.X.Y oder libxxx.X.Z vorhanden ist. Oder umgekehr formuliert, die minor-Lib-Versionnumbers räumen Lib-Entwicklern die Möglichkeit ein, Updates/Bug-Fixes oder Erweiterungen von Libs herauszubringen, ohne die Binärkompatibilitärt zu vernichten und User zu Upgrades zu zwingen. Nur so ist es z.B. möglich, dass Programme, die gegen glibc-2.2.1 gelinkt sind auch noch unter glibc-2.2.3 laufen. (Eine detailierte Diskussion dieses Themas ist in libtool.info zu finden).
Und was ist, wenn er eine höhere hauptversion hat?
Auch dann funktioniert es nicht und das ist gut so! Eben weil dem so ist, können Programme koexistieren, die unterschiedliche Versionen der gleichen Bibliothek verwenden.
Wieso? Wenn alles auch mit der neusten Version liefe, dann gäb es doch auch keine Probleme. In einer idealen Welt gäbe es diese Probleme auch nicht ;) Leider ist die Welt nicht ideal, ausserdem gehen viele Autoren von Libs gehen recht sorglos mit der Lib-Versionierung um.
Die lib<name>.so Dateien werden i.d.R. ausschliesslich vom statischen Linker zum Erstellen des Programmes benötigt.
Du meinst lib<name>.a so steht für shared object, a für archiv.
Nein, ich meinte durchaus lib<name>.so. Beachte, dass ich vom statischen Linker, also dem normalen ld und nicht vom statischen Linken sprach.
Huch, ich kenne nur den ld. Das ist der statische Linker
Was ist denn ein dynamischer Linker? Auch Runtime-Linker seltener auch Startup-Linker genannt. Er durchsucht, beim Start von dynamisch gelinkten Programmen, diese nach dynamisch gelinkten Libs und lädt sie hinzu. (Siehe man ld.so).
Ralf
* Ralf Corsepius schrieb am 02.Sep.2002:
Die Versionierung einer Library deren Nutzung durch ein Programm das von Dir beschriebene Verhalten zeigt ist defekt, da per Definition alle libxxx.X.Y und libxxx.X.(Y+n) (mit n >= 0) binär-kompatibel seien _müssen_.
Genauso habe ich es bisher auch angenommen. Ist ja irgendwie logisch.
Nur so ist es z.B. möglich, dass Programme, die gegen glibc-2.2.1 gelinkt sind auch noch unter glibc-2.2.3 laufen.
Aber ein Programm, daß gegen glibc-2.2.3 gelinkt ist, braucht nicht unbedingt mit glibc-2.2.1 zu laufen, oder? Und was ist mit Programmen, die gegen glibc-2.1.x glinkt sind? Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Am Montag, 2. September 2002 12:40 schrieb Bernd Brodesser:
Aber ein Programm, daß gegen glibc-2.2.3 gelinkt ist, braucht nicht unbedingt mit glibc-2.2.1 zu laufen, oder?
Als bei der glibc 2.2.x sollte es keine Probleme geben. SuSE 7.3 Programme (glibc 2.2.4) sind immer problemlos auf meiner 7.1er (glibc 2.2.0) gelaufen, bis ich selbst auf 7.3 umgestiegen bin (und dort nun die 2.2.5er laufen habe, wär ja noch das schönere, wenn da auch nur ein Paket original bliebe ;-) ).
Und was ist mit Programmen, die gegen glibc-2.1.x glinkt sind?
Die glibc bietet libs zur rückwärtskompatibilität. Damit sollten eigentlich die 2.0er und 2.1er gelinkten Programme problemlos laufen (tun sie normalerweise auch). Andersrum geht die Sache nicht, gegen glibc 2.2 gelinkte Programme wird man unter 2.1 oder 2.0 nicht zum laufen kriegen (Ausnahmen mögen die Regel bestätigen). Ist allerdings nicht so, dass jede Library das so handhaben muß. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de
*** Bernd Brodesser (B.Brodesser@t-online.de) schrieb in suse-linux heute:
[...] Da haben wir anscheinend aneinander vorbeigeredet. Angenommen ein Programm ist auf libname.so.<hauptversion> gelinkt und libname.so.<hauptversion> ist ein SymLink (Oh, oh, hier hat das Wort link eine vollkommen andere Bedeutung) auf libname.so.<hauptversion>.<minorversion>. Ich installiere mir dieses Programm und ich habe auch libname.so.<hauptversion> bei mir ist es aber ein Symlink auf libname.so.<hauptversion>.<neuereminorversion>
Wenn das Programm dann bei mir nicht läuft, dann könnte man sich das mit major- und minorversion auch schenken und nur eine Versionsnummer verteilen.
Ähmm... Diese Argumentation geht in die Richtung "Wenn sich jemand ein Auto ohne Sichheitsgurte kauft, damit gegen eine Wand fährt und tot ist, kann man sich in Autos ja gleich die Sicher- heitsgurte schenken". Wenn ein Programmierer nur mit einer major version linkt, obwohl er sich klar ist, dass sich bei einem minor version change bestimmte für sein Programm kritische Funktionsprofile ändern können, sollte man ihn freundlich bitten, dass zu ändern. Falls Du die Sourcen hast, kannst Du auch versuchen - eigentlich sollte das sogar kein Problem sein - mit der major.minor version dnaymisch zu linken.
[...]
MfG Henning Hucke
--
"24-Aug-95 10:55:52 1> too many flames, message base is melting."
Matthias Scheler in
* Henning Hucke schrieb am 02.Sep.2002:
Ähmm... Diese Argumentation geht in die Richtung
"Wenn sich jemand ein Auto ohne Sichheitsgurte kauft, damit gegen eine Wand fährt und tot ist, kann man sich in Autos ja gleich die Sicher- heitsgurte schenken".
Ich habe nicht argumentiert, sondern nur gefragt, ob ich richtig verstanden habe, wie es funktioniert. Ich habe nicht vor irgendwelche libs zu erstellen. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
On Sun, 01 Sep 2002 at 04:51 (+0200), Philipp Thomas wrote:
Die lib<name>.so Dateien werden i.d.R. ausschliesslich vom statischen Linker zum Erstellen des Programmes benötigt.
Sicher? Zum statischen Linken wird doch normalerweise lib<name>.a verwendet. Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ The Internet is not a primary goal for PC usage -- Bill Gates (1995)
Bernhard Walle
Die lib<name>.so Dateien werden i.d.R. ausschliesslich vom statischen Linker zum Erstellen des Programmes benötigt.
Sicher? Zum statischen Linken wird doch normalerweise lib<name>.a verwendet.
Siehe auch meine Antwort an Bernd. Ich sprach vom statischen Linker ld (im Gegensatz zum dynamischen Linker ld-linux.so) und nicht vom statischen Linken. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
Am Die, 27 Aug 2002 schrieb Michael Messner:
Hallo Liste,
jetzt bin ich nochmal mit ner Frage zum Installieren von Programmen da:
Man findet ja im Netz so einige rpm's, die großteils für ältere Linuxversionen sind! Kann ich die auf ner neuen Version (z.B.8.0) ebenso (ohne Bedenken) installieren oder kann (bzw. kommt) es da zu Konflikten kommen?
Na, sicher gehen kannst Du natürlich nicht, daß es klappt, da aber die meisten Bibliotheken unter Linux abwärtskompatibel gehalten sind, geht es häufig, zumindest solange die Sprünge nicht zu groß sind. Aber es gibt auch Gegenbeispiele. So wirst Du ein Programm, das QT1 braucht, mit Deiner QT3 nicht mehr ausführen können. Aber im Zweifel probieren und wieder verwerfen...
Kann man da eine generelle Auskunft geben oder muss man da probieren? Oder gibt es da Versionen die generell miteinander können und andere wieder nicht?
Da gilt natürlich immer, je näher die Versionen sind, desto besser, was aber generell nicht geht (zumindest nicht ohne Zusatzinstallationen) sind Programme, die z.B. noch libc5 erwarten, nicht glibc (Maple V.4 war so ein Kandidat). Kritisch wird es (so als Faustregel), wenn die Major-Release-Number wechselt.
Da werden dann ja immer mehr die typischen Windows Probleme sichtbar (auf der Version läufts, auf der anderen wieder nicht)! (Zerreisst mich jetzt nicht wegen der Aussage, wenn ich mich irre berichtigt mich aber bitte!) Mit der Ausnahme dass man sich halt meist mit den Src. selbst helfen kann!
ACK. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Dienstag, 27. August 2002 16:21 schrieb Michael Messner:
Man findet ja im Netz so einige rpm's, die großteils für ältere Linuxversionen sind! Kann ich die auf ner neuen Version (z.B.8.0) ebenso (ohne Bedenken) installieren oder kann (bzw. kommt) es da zu Konflikten kommen?
Im allgemeinen gibts keine Probleme, habe auch noch 6.1er RPMs auf meiner 7.3. Ab 7.1 ist auch die glibc compatibel bis hoch zur 8.0 (und wohl auch 8.1).
Kann man da eine generelle Auskunft geben oder muss man da probieren?
Es gibt einige mögliche Probleme, wenn z.B. bestimmte Bibliotheken in einer speziellen Version vorliegen müssen. Problematisch sind auch Dämonprozesse, da SuSE von der 7.3er zur 8.0er die Startmechanismen umgestellt hat. Eine 100% Garantie gibts also nicht, da hilft oft nur ausprobieren. Ist aber prinzipiell kein Problem, da RPMs sich ja schnell wieder deinstallieren lassen.
Oder gibt es da Versionen die generell miteinander können und andere wieder nicht?
Generell sind SuSE 7.1 bis 7.3 sehr unproblematisch, aber auch da gibts keine Garantie. Die 8.0 hat durch Änderung von Startmechanismen ne zusätzliche Hürde, ist sonst aber auch sehr handsam.
Da werden dann ja immer mehr die typischen Windows Probleme sichtbar (auf der Version läufts, auf der anderen wieder nicht)!
Zum glück so nicht. Meist belaufen sich die nötigen Handarbeiten auf die Installationen der benötigten Libs in der nötigen Version begrenzen. Zum Glück ist unter Linux die Installation unterschiedlicher Versionen der gleichen Lib auch recht unproblematisch. Nen richtigen Schnitt wirds dann wohl bei 8.1 geben, wenn ein 3.2er gcc eingesetzt wird.
(Zerreisst mich jetzt nicht wegen der Aussage, wenn ich mich irre berichtigt mich aber bitte!)
Nö, existierende Probleme dürfen Angesprochen werden. SuSE bemüht sich ja auch redlich der LSB Rechnung zu tragen. Wenn das mal jeder Distributor macht, wird uns in Zukunft einiger Ärger erspart bleiben und die Installation eines z.B. Mandrake RPM's auch problemlos klappen.
Mit der Ausnahme dass man sich halt meist mit den Src. selbst helfen kann!
Das auch ;-) -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de
participants (13)
-
B.Brodesser＠t-online.de -
Bernhard Walle -
Christoph Maurer -
David Haller -
Heinz W. Pahlke -
Henning Hucke -
Manfred Tremmel -
Michael Messner -
Michael Raab -
Pascal Volk -
Philipp Thomas -
Ralf Corsepius -
Sven Gehr