Vielen Dank für Deine schnelle Antwort Am Montag, 3. Januar 2005 23:55 schrieb Philipp Thomas:

Ulf Möller [Mo, 3 Jan 2005 20:29:57 +0100]:

...

ABER: Fehler bei den Abhängigkeiten, da z.B. libmp3lame (lame-Paket) benötigt wird, dass sich aber nicht in /usr/lib sondern in /usr/lib64 befindet (64Bit-Version installiert).

Ja, da braucht es die 32bittige Version der Bibliothek. Bei uns sind solche Bibliotheken in extra Paketen untergebracht (mit 32-Bit im Namen). Natürlich nur für Pakete, die Teil der Distribution sind. Bei Paketen von Packman müsste dort ein entsprechendes Paket zusammengestellt werden.

Das hab ich mir schon gedacht, dass man für 64Bit-Programme die passenden 64Bit-Bibliotheken benötigt. Solange man nur die Programme von SuSE 9.2 verwendet, funktioniert ja auch alles, aber das es beim ersten Installieren von fremden Programmen Probleme gibt, ist nicht Sinn und Zweck eines Betriebssystems. Theoretisch würde das heissen, dass man sowohl die 64, als auch die 32 Bit-Bilbiotheken einspielen müßte, das geht aber auch nicht, da i.d.R. diverse Files aus den 32Bit-Paketen mit denen aus den 64-Bit in Konflikt miteinander geraten. Also nur 64-Bit-Programme bzw. immer alle Pakete selber bauen ? ( lieber nicht) Und wenn es keine 64-Bit-Pakete gibt, kann man diverse Programme nicht einsetzen, na denn Prost Neujahr.

...

Installiert man mit --nodeps bekommt man das Problem beim Aufruf vom MPlayer. Ein symbolischer Link hilft hier auch nicht weiter.

Nein, hier braucht es extra RPMs. Du könntest z.B. diese zusätzlich benötigten Bibliotheken aus den entsprechenden Paketen herausziehen und in ein extra RPM packen. Dann wären die Abhängigkeiten befriedigt. Das wäre ziemlich aufwändig... und für den Otto-Normal-Verbraucher gar nicht machbar !

...

Wie geht man/ihr damit um, gibt es einen vernünftigen Workaround ? Vor diesem Problem müßten doch alle Distris stehen ?

Es ist ja auch nicht möglich, SuSE 9.2 nur im i386-Modus zu installieren (ist mir zumindest nicht geglückt).

Ich zumindest stehe kurz davor, wieder SuSE 9.1 (i385-Modus) zu installieren und mir dann eine andere Distri zu suchen...

Das hat aber mit SUSE nur bedingt zu tun. Für Pakete, die wir auf der Distribution haben, wird, wo nötig, die 32bit Bibliothek zur Verfügung gestellt. Für Pakete aus anderen Quellen sind wir nicht zuständig, da musst du dich schon an diese Quellen wie eben Packman wenden oder aber selber RPMs basteln und entsprechend aktualisieren.

Ich bin seit einer der ersten Disketten-Distri von SuSE (ca. 25 Disketten) dabei und weiss, dass das mit SuSE direkt nichts zu tun hat. Andere Distris wie Knoppix,, Debian und Co. dürften vor dem selben Problem stehen. Nur: Meiner Meinung nach hat Linux ein generelles Problem: Installation !!!!! Solange das Installieren von Programmen nicht einfacher wird, wird es den Massenmarkt nie erreichen ! (einige von Euch wollen das ja auch gar nicht - bitte keine Diskussion hierüber). So wie es jetzt mit den 64-bittigen Programmen / libs aussieht, kann man von einem 64-Bit Linux nur dringend abraten.

Hallo Detlef, Am Dienstag, 4. Januar 2005 12:20 schrieb Detlef Reichelt:

Am Montag, 3. Januar 2005 20:29 schrieb Ulf Möller:

...

Mein größtes Problem ist die Mischung von i386 und x64.Programmen. Beispiel: Habe mir MPlayer von packman gezogen, Paket gibt es aber nur für i386 und kompilieren brachte in der Vergangenheit auf SuSE-Systemen immer Probleme. [...]

unter ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.2-x86_64/RPMS.suser-j morris findest du den MPlayer 1.0.pre5 für x86_64

Vielen Dank für den Link, damit ist mein aktuelles Problem immerhin gelöst. Generell sehe ich die 64-Bit-Umsetzung aber weiterhin als problematisch an. Ulf

Am Dienstag, 4. Januar 2005 16:03 schrieb Philipp Thomas:

* Ulf Möller (u.moeller@gmx.de) [20050104 15:42]:

...

Generell sehe ich die 64-Bit-Umsetzung aber weiterhin als problematisch an.

Was daran ist problematisch? Die Grenzen setzt hier die Hardware, nicht das Betriebssystem.

Erstmal vorweg: Ich greifen niemanden an, auch nicht SuSE, also die Krallen bitte wieder einfahren. Ich möchte verstehen, was ein 64-Bit Linux mit 64Bit-LIBs und 32Bit-Libs macht und wie diese parallel installiert werden können. Ich installiere meine erste 64-Bit-Linux-Version und versuche nur, das Konzept, welches hier hinter steht, zu verstehen (und seine Auswirkungen) Ich schildere jetzt einfach mal meine Vorgehensweise: 1) SuSE 9.2 64-Bit wird installiert (funktioniert super, mit die Beste SuSE-Installation seit langem, riesen Lob... alles wird erkannt 2) Ich versuche Moneyplex zu starten und stelle, fest, meine Chipkarten-Treiber sind nicht installiert, also DVD rein und die Towitoko-Treiber installieren. SuSE nimmt jetzt automatisch die 64-Bit-Treiber (wie man im RPM-System sehen kann). 3.) In Moneyplex will ich die Treiber auswählen und nun sagt mir das Programm (bei dem es sich um ein 32-Bit-Programm handelt, was der normale Anwender aber nicht weiss !), dass das keine Chipkarten-Treiber sind. Warum das keine seinen sollen, sagt niemand, um welche Bit-Version es sich bei den Programmen handelt, weiss der Anwender normalerweise auch nicht. 4.) Ich schliesse auf eine fehlerhafte rpm-Datei und hole mir die tar-Files. Schnell compiliert, Moneyplex aufgerufen und ... dieselbe Sch*** (jetzt klar, da 64-Bit-Treiber erzeugt wurden) Also manuell im i586-Verzeichnis der DVD die pcsc-towitoko.rpm rausgesucht und installiert Nun geht es ! ABER: Eine andere (fiktive) 64-Bit-Anwendung, die den Towitoko-Treiber benötigt, funktioniert nun nicht mehr !!! Beide Pakete (32Bit und 64Bit) kann ich nicht installieren (package pcsc-towitoko-1.1.1-248 is already installed) Ich muss also auf eine Anwendung verzichten !

Die Probleme, auf die du hier stösst haben mit dem Betriebssystem erst einaml nichts zu tun. Doch ! Mit was sollen die denn sonst zu tun haben ! Wenn man natürlich als BS nur den Kernel sieht, dann hast Du recht, für mich ist ein BS die gesammte Architektur (incl. Bibliothekenverwaltung, Programmverwaltng usw.) (Ich weiss, dass man hierüber ganze Doktorarbeiten schreiben kann und sich die Gelehrten hierüber streiten)

...

Theoretisch würde das heissen, dass man sowohl die 64, als auch die 32 Bit-Bilbiotheken einspielen müßte, das geht aber auch nicht, da i.d.R. diverse Files aus den 32Bit-Paketen mit denen aus den 64-Bit in Konflikt miteinander geraten.

Die zur Laufzeit benötigten Bibliotheken überschneiden sich nicht und nur die werden benötigt. Das funktioniert prima! Das Beispiel oben zeigt, dass es nicht geht. Hier steht zwar nur die RPM-Verwaltung im Wege, aber der normale Anwender ist jetzt aufgeschmissen. Bei der Bibliothek libdv sieht das aber schon ganz anders aus: Hier überschneiden sich die Files im Verzeichnis /usr/bin (file /usr/bin/dubdv from install of libdv-*** conflicts with file from package libdv.****) Hier muss der Anwender jetzt schon sehr genau wissen, was er tut.

Zur Laufzeit überschneiden sich die Pakete in der Tat nicht (wir sind ja zum Glück nicht bei M$)

...

Solange das Installieren von Programmen nicht einfacher wird, wird es den Massenmarkt nie erreichen ! (einige von Euch wollen das ja auch gar nicht - bitte keine Diskussion hierüber).

Wo ist das Installieren schwierig? Der RPM-Mechanismus schlägt den in Windows verwendeten um Längen! Oder willst du jetzt auch unter Linux Pakete, die dir mal eben Systembibliotheken wie glibc mit einer anderen Version überschreiben? Der RPM-Mechanismus mit seinen ganzen Abhängigkeiten ist IMHO extrem anfällig. Entweder ich mache alles über RPM oder gar nichts ! Beispiel 1: Firefox 1.0 PRE Engl. wurde von SuSE mitgeliefert und ist ein RPM-Paket Ich habe mir die neue Version 1.0 gezogen und mittels vorgegebenen Script installiert. Oh, jetzt habe zweimal Firefox installiert, also schnell RPM-Version deinstallieren Und schon weiss das RPM-System nicht mehr, dass ich Firefox installiert habe Die Firefox-Version aus dem Internet kann ich nicht über RPM-Installieren.

Beispiel 2: Ich installiere ein tar-File mit make install. Auch hier bekommt RPM nichts mit. Also muss man z.B. checkinstall verwenden. Beispiel 3: Es kam in der Vergangenheit öfters vor, dass ich eine neuere LIB benötigte. Die Namensgebung der RPMs ist aber jedem RPM-Bauer selbst überlassen, so dass eine neuere Version der LIB (aus dem Internet) einen anderen Namen als der orig. SUSE-RPM-Name war. Dadurch kam die gesammte RPM-Verwaltung durcheinander. (ich kann den Vorgang nicht genau erklären, so tief stecke ich in dem RPM-Kram nicht drinne und ist auch schon über 6 Monate her).

...

So wie es jetzt mit den 64-bittigen Programmen / libs aussieht, kann man von einem 64-Bit Linux nur dringend abraten.

Dem kann ich nur widersprechen. Bei mir funktioniert es prächtig und nicht jeder braucht proprietären 32Bit Kram. Du kannst dir z.B. prima einen (fast) vollständigen 64Bit MPlayer bauen. Nur auf die Windows-Codecs musst du verzichten, denn die sind 32bittig. Stop ! Warum soll ich auf die W32-Codecs verzeichten ? Das will und kann ich nicht ! Schon muss der MPlayer 32-Bittig sein und so weiter. Du wirst nur dann auf 32Bit Kram verzeichten können, wenn Du ausschließlich auf OpenSource setzt und zur Not alles selbst compilieren kannst. Das geht doch schon bei der o.g. Banking-Software los. Die OpenSource-Treiber unterstützen nur einen Bruchteil der sich am Markt befindlichen Chipkarten und Authentifikationsmöglichkeiten. Und von solchen Bereichen gibt es sicherlich noch mehr.

BTW, auf einem 64bittigen Windows wird man dieselben Schwierigkieten haben, denn - oh Wunder - auch Windows kann nicht 32bittigen und 64bittigen Code mischen. Ach ja, 16bittige Windowssoftware wird dann garnicht mehr unterstützt. Ich habe die 64Bit-Version nicht ausprobiert. Ich kann mir aber nicht vorstellen, dass ein 64Bit-VB-Runtime -Paket sich nicht installieren lässt, nur weil bereits ein 32Bit-VB-Runtime-Paket bereits installiert wurde (das würde in etwas dem obigen RPM-Problem entsprechen.

Tschüß Ulf

Ulf Möller [Di, 4 Jan 2005 20:41:45 +0100]:

3.) In Moneyplex will ich die Treiber auswählen und nun sagt mir das Programm (bei dem es sich um ein 32-Bit-Programm handelt, was der normale Anwender aber nicht weiss !), dass das keine Chipkarten-Treiber sind. Warum das keine seinen sollen, sagt niemand, um welche Bit-Version es sich bei den Programmen handelt, weiss der Anwender normalerweise auch nicht.

Beschwere dich bei Matrica, schliesslich haben die Moneyplex programmiert.

Eine andere (fiktive) 64-Bit-Anwendung, die den Towitoko-Treiber benötigt, funktioniert nun nicht mehr !!! Beide Pakete (32Bit und 64Bit) kann ich nicht installieren (package pcsc-towitoko-1.1.1-248 is already installed)

Es kommt darauf an, was du Treiber nennst. Wenn es Kerneltreiber wären, hättest du schon verloren, denn ein 64bittiger Kernel braucht *zwingend* auch 64bittige Treiber.

Ich muss also auf eine Anwendung verzichten !

Da müsste dann in der Tat das Paket so modifiziert werden, das 64bittige Programme woanders installiert werden.

Doch ! Mit was sollen die denn sonst zu tun haben ! Wenn man natürlich als BS nur den Kernel sieht, dann hast Du recht, für mich ist ein BS die gesammte Architektur (incl. Bibliothekenverwaltung, Programmverwaltng usw.)

Ein 32bittiges Programm kann auch nur mit 32bittigen Programmen bzw. Bibliotheken kommunizieren und umgekehrt, das ist eine Limitierung der Hardware.

Bei der Bibliothek libdv sieht das aber schon ganz anders aus: Hier überschneiden sich die Files im Verzeichnis /usr/bin (file /usr/bin/dubdv from install of libdv-*** conflicts with file from package libdv.****)

Ja, bei solchen Fällen wird es knifflig, denn es gibt keine getrennten Verzeichnisse für Programme. Das würde auch nicht viel Sinn machen, denn der Anwender käme damit bestimmt nicht mehr klar.

Der RPM-Mechanismus mit seinen ganzen Abhängigkeiten ist IMHO extrem anfällig.

Das hat mit anfällig gar nichts zu tun.

Entweder ich mache alles über RPM oder gar nichts !

Ja, das ist nunmal so, denn RPM kann weder hellsehen noch zaubern, also kann es nicht erraten, was du an RPM vorbei installiert hast. Wenn es ein zentrales Installationsprogramm gibt, *muss* es verwendet werden, wenn man ein konsistentes System haben will. BTW, RPM ist das nach LSB standardisierte Installationsprogramm.

Beispiel 1: Firefox 1.0 PRE Engl. wurde von SuSE mitgeliefert und ist ein RPM-Paket Ich habe mir die neue Version 1.0 gezogen und mittels vorgegebenen Script installiert. Oh, jetzt habe zweimal Firefox installiert, also schnell RPM-Version deinstallieren Und schon weiss das RPM-System nicht mehr, dass ich Firefox installiert habe Die Firefox-Version aus dem Internet kann ich nicht über RPM-Installieren.

Nein, aber unter /pub/projects/mozilla/firefox auf ftp.suse.com oder seinen Spiegeln (z.B. ftp.gwdg.de) gibt es 1.0 RPMs, die tun prima :)

Beispiel 2: Ich installiere ein tar-File mit make install. Auch hier bekommt RPM nichts mit. Also muss man z.B. checkinstall verwenden.

Ja, da ist Arbeit angesagt. Aber ich würde erst mal bei Quellen wie packman nachschauen, ob da evtl. schon jemand RPMs gebaut hat. Ansonsten musst du entweder checkinstall verwenden oder aber eben dir deine eigenen echten RPMs bauen. Das wird dir mit *allen* Paketen so gehen, die kein RPM verwenden.

Die Namensgebung der RPMs ist aber jedem RPM-Bauer selbst überlassen, so dass eine neuere Version der LIB (aus dem Internet) einen anderen Namen als der orig. SUSE-RPM-Name war. Dadurch kam die gesammte RPM-Verwaltung durcheinander.

Ja, da musst du dir schon das ältere Paket anschauen und dann entsprechend das neue Paket konfigurieren.

Stop ! Warum soll ich auf die W32-Codecs verzeichten ? Das will und kann ich nicht ! Schon muss der MPlayer 32-Bittig sein und so weiter.

Die W32-Codecs sind binärer 32bittiger Windows-Code, mit dem *kann* nur ein 32bittiges Programm kommunizieren. Für einen 64bittigen MPlayer müssten die Codecs in 64bittiger Form vorliegen und selbst dann müsste höchstwahrscheinlich MPlayer angepasst werden, weil in 64bittigem Windows einige fundamentale Datentypen eine andere Grösse als in Linux für AMD64 haben.

Ich kann mir aber nicht vorstellen, dass ein 64Bit-VB-Runtime -Paket sich nicht installieren lässt, nur weil bereits ein 32Bit-VB-Runtime-Paket bereits installiert wurde (das würde in etwas dem obigen RPM-Problem entsprechen.

Nein, denn der von M$ verwendete Installer hat weitaus weniger Eigenintelligenz als RPM. Und auch unter Windows64 wird ein 32bittiges Moneyplex nicht mit 64bittigen Treibern funktionieren :) Philipp