Nebenbei: eCS ging nur bis 2.2 beta 2 [hab mich selbst korrigiert - wie peinlich!].
Firefox wird von Bitwise Works portiert. Deshalb gibt es
dort auch immer den aktuellen Download.
Zum eigentlichen Thema: Welche RPM-Pakete installiert werden müsenn, ist in
README.OS2 der entsprechenden Release-Version aufgelistet [Link geändert].
Zur einfachen Installation der .rpm-Pakete ist
ANPM zu empfehlen. Unter YUM -> Schnellinstallation... kann man auch eine von Leerzeichen getrennte Liste an Paketnamen eingeben, wie sie in README.OS2 angegeben werden.
Damit Probleme in Verbindung mit der verallteten RPM/Python/YUM-Umgebung, die bei eCS dabei ist, gar nicht erst auftreten, würde ich auf der
Arca-Noae-Seite nachlesen. Da gibt es
wichtige Tipps zu eCS und YUM, die man so sonst nicht beschrieben findet. Es ist sehr zu empfehlen in der dort angegebenen Reihenfolge vorzugehen.
In der Vergangenheit gab es häufig Ärger mit YUM, RPM-Paketen und DLLs. Die DLL-Hölle haben wir mit OS/2 schon lange. Dadurch, dass häufig neue Versionen erscheinen, kommt es auch häufiger zu Fehlern und Inkompatibilitäten. Zum Glück haben die Entwickler es verstanden, den Schaden zu minimieren, wenn auch zu spät: Aktuell portierte DLLs enthalten immer die Versionskennung im Dateinamen. (Das ist unter OS/2 nicht einfach, weil DLL-Namen auf 8+3 Zeichen begrenzt sind.)
Außerdem sorgen die Entwickler bei neueren RPM-Pakete dafür, dass die Ausführbarkeit von älteren Anwendungen bewahrt bleibt. Extremes Beispiel ist die aktuell gcc1.dll aus dem Paket libgcc1. Das enthält die aktuelle Runtime-DLL in der Version 4.9.2.1-3. Diese Versionskennung bekommt man nicht in 3 Zeichen für gcc und 5 restlichen Zeichen unter. Hier wurde deshalb abweichend von dem, was ich ober geschrieben hab, die Versionskennung auf eine Stelle reduziert, die immer für die neueste Version steht. Daneben wird auch das Paket libgcc-fwd installiert. Das enthält etliche DLLs, bis hin zur aktuellen gcc492.dll, die alle auf gcc1.dll verweisen und damit auch etwas Platz sparen.
Nachteilig bei YUM in Verbindung mit Python ist es, dass eine komplexe Ebene hinzugefügt wurde, die selbst nicht fehlerfrei ist, auch betriebssystemübergreifend. Zusätzlich wurden in der Vergangenheit immer wieder Pakete bereitgestellt, die selbst zu Problemen geführt haben, z.B. weil sie fehlerhaft waren. Auch die Integration in eCS 2.2 beta 2 ist nicht perfekt gemacht. Mit ANPM wird es deutlich einfacher, aber die Fehler aus der Vergangenheit muss man trotzdem erstmal beheben. Eine Schwachstelle des Paketmanagers YUM ist es, dass er selbst etliche Pakete benötigt. Dazu gehören viele, die er auch selbst installiert und updatet. Dabei kann es leichter passieren, dass die Ausführung von YUM selbst nicht mehr problemlos funktioniert.
Ein weitere Nachteil von RPM-Paketen ist der, dass sie nur mit relativ viel Übung zu erstellen sind. Das Zusammenstellen von WarpIN-Paketen ist erstmal einfacher, das von brauchbaren WarpIN-Paketen aber genau so schwierig wie das von RPM-Paketen.
Ach ja: Es existieren auch ZIP-Dateien zur Installation der DLLs und Zusatzdateien,
hier z.B. für die Mozillen. Meine Meinung ist die: Wenn man ein lauffähiges System mit erfolgreichem YUM, besser noch ANPM hat, dann kann man mal versuchen sich danach an eins ohne diese Werkzeuge heranzuwagen und entweder RPM- oder ZIP-Dateien auszupacken und die Dateien von Hand zu verschieben, wo es am besten gefällt. Die Versionskontrolle entfällt aber, so dass der Schwierigkeitsgrad damit enorm ansteigt. Gerade mit vielen portierten Anwendungen wird es fast unmöglich alles von Hand zu pflegen.
Die Entwickler stellen die ZIP-Dateien zwar auch bereit, aber unterstützen eigentlich nur die Installation über die RPM-Pakete. Das könnte damit zu tun haben, dass vorgegebene Umgebungen (gerade bei der heutigen Dateianzahl) viel einfacher zu unterstützen sind als die, die damals mit OS/2 ausgeliefert wurden, zumal sich IBM ja bekanntlichermaßen selbst nicht an ihre eigenen Regeln gehalten hat. Die Zeiten sind einfach nicht mehr vergleichbar.