yum/rpm installieren

(DE) Fragen, Meinungen, Wünsche, Fehlermeldungen zum Forum und os2.org
(EN) Questions, ideas, wishes, errors, eg. to the forum and os2.org
Siegfried

yum/rpm installieren

Post by Siegfried » Mon 28. Mar 2016, 17:46

Hi OS2/ECS user,

Ich möchte den Firefox 10.xx im ECS2.2B3 ersetzen. Nachdem ich die Vorausetzungen im README gesehen habe und annehmen kann zukünftige FFs bestimmt die gleichen Voraussetzungen braucht oder mehr das RPM zu installieren.

Frage 1: gibt es eine Internetadresse zum herunterladen?

Frage 2: gibt es dazu auch eine Installationsanweisung, eventuell auch eine Bedienunganw. dazu?

Danke im Voraus, Karl

Werner.S
Posts: 89
Joined: Mon 23. Dec 2013, 11:29
Location: Nürnberg

Post by Werner.S » Mon 28. Mar 2016, 19:42

Hi
Hier kannst du dir einen aussuchen.

http://www.ecsoft2.org/firefox

Tom

Post by Tom » Mon 28. Mar 2016, 19:43

Beide Fragen werden beantwortet bei Netlabs:

trac (dot) netlabs (dot) org (slash) rpm (slash) #Installation

aschn
Posts: 690
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Mon 28. Mar 2016, 21:53

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.
Last edited by aschn on Thu 31. Mar 2016, 19:02, edited 4 times in total.
Andreas Schnellbacher

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Wed 30. Mar 2016, 10:17

Es ist schon etwas zynisch, auf die Readme.os2 angesichts der Probleme der Benutzer zu verweisen.

Egal ob man ZIP oder RPM wählt - man sollte sein System vorab (vorsichtig) aufräumen. Keine der Installationsmethoden nimmt einem diese Arbeit ab.

D.h. man muß einen Abgleich aller im Libpath und ggf. auch in Programmverzeichnissen liegenden DLLs durchführen. Es gibt zZ. drei Hauptstrukturen:
c:\os2
c:\ecs
sowie die UNIXROOT Verzeichnisse
c:\usr
c:\var
c:\etc

c: = Bootlaufwerk

Relevant sind natürlich die Unterverzeichnisse der o.g. Verzeichnisse, wie zB. \bin, \lib, \dll etc.

Ein Reduzierung der Libpath-Verzeichnisse ist für den besseren Überblick sinnvoll. c:\ecs\dll habe ich hier zB. inzwischen komplett abgeschafft, das Verzeichnis ist leer. Alle benötigten DLLs liegen unter \os2\dll, dann gibt es auch keine Duplikate und man vermeidet dadurch schonmal ein Problem. Fontconfig liegt im Unixroot. Ev. erbarmt sich ja noch ein Programmierer, und fügt ein OS2 konformes Auffinden der benötigten Dateien über Path/Libpath hinzu, oder erlaubt normale relative Unterverzeichnisse.

Zu beachten ist, dass für die neuen FF und Seamonkey Versionen UNIXROOT gesetzt werden muß. Genauer gesagt wird es nur für das neue (und benötigte) FONTCONFIG benötigt, die restlichen Komponenten arbeiten auch ohne UNIXROOT. Für FONTCONFIG muß auch die Verzeichnisstruktur unterhalb UNIXROOT beachtet werden. Wenn man das weiß (und wenn es dokumentiert wäre), ist die Installation von SM oder FF mit den Archiven aus http://os2news.warpstock.org/Warpzilla.htmleine Sache von 3 Minuten (ohne die Aufräumarbeiten).

Zumindest bei den neuen DLLs, die mit neuen FF und SM-Versionen kommen, sollte man das System nach Duplikaten und älteren Versionen durchsuchen, und diese entfernen. Eine Sicherung des Systems im Fall von Nebenwirkungen der Aufräumarbeiten sollte man parat haben.

Eine Alternative zB. bei nicht auffindbaren Problemen ist, ein komplett privates Environment für die Browser anzulegen. In dem Fall werden alle DLLs und Dateien in ein privates Verzeichnis gelegt (für FONTCONFIG die Unterverzeichnisse beachten), und UNIXROOT und LIBAPTH werden entsprechend in Environmentvariablen nur für die FF oder SM Session gesetzt.

Wer viele der Unixports (zB. von Netlabs) einsetzt, sollte sich wohl eher einen systemweiten und sauberen UNIXROOT anlegen.

User avatar
ak120
Posts: 900
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Wed 30. Mar 2016, 11:23

aschn » Mo 28. Mär 2016, 21:53 wrote:Nebenbei: eCS ging nur bis 2.0 beta 2.

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.
Dort wird gern mal das ein oder andere vergessen, bzw. eine falsche Version erwähnt, da anscheinend nach dem Copy-Paste-Verfahren kein Korrekturlesen stattfindet. Bei Hinweisen zu möglichen Fehlern und Falschdarstellungen wird seitens bitweise sehr dünnhäutig reagiert. Erst nach massiven Beschwerden werden Documentation Bugs (leider auch nur unvollständig) behoben.
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...
Alles was hier von Andreas weiter geschrieben wurde ist mehr oder weniger zutreffend, aber leider m.E. nicht immer zielführend. Die wenigen Ungenauigkeiten (DLL-Dateien) möchte ich nun nicht zur Haarspalterei heranziehen.

Es fehlen eindeutig Warnhinweise, RPM/YUM + ANPM keinesfalls auf Produktionssystemen zu installieren. Keinerlei Änderungen an der Systemkonfiguration (CONFIG.SYS) zulassen bzw. nicht ohne Revision vorzunehmen. Hier sei insbesondere auf die Suchpfadänderung (PATH) verwiesen, welche schnell nicht bestehende Verzeichnisse (\usr\local\bin) dort weit vorn einträgt, was sehr lustige Effekte habe kann. Da gerade (wie von Frank beschrieben) die Leiden unter eComStation noch stärker auftreten können, scheint es ratsam zur Erprobung einer Firefox- oder Seamonkey-Testversion, die Bibliotheken im Anwendungsverzeichnis zu halten.

Da eine beta 7 von bitwise Firefox in weiter Ferne liegt bzw. momentan überhaupt keine nachvollziehbare Entwiclung mehr stattfindet, sollte man weder auf Ersatz noch Entsatz hoffen.

User avatar
thorolf
Posts: 363
Joined: Wed 25. Dec 2013, 16:14
Location: Rhein-Main

Post by thorolf » Wed 30. Mar 2016, 13:08

ak120 » Mi 30. Mär 2016, 11:23 wrote:Es fehlen eindeutig Warnhinweise, RPM/YUM + ANPM keinesfalls auf Produktionssystemen zu installieren. Keinerlei Änderungen an der Systemkonfiguration (CONFIG.SYS) zulassen bzw. nicht ohne Revision vorzunehmen.
das ist insofern "Quatsch", weil es im Grunde keine aktuelle "Nicht-Beta" oder gar "Nicht-Alpha"-Software für OS/2 gibt, selbst die letzte, von vielen "produktiv" eingesetzte eCS ist maximal Beta. Dazu kommt, das es praktisch gar keine Alternative gibt

Selbst wenn es neue Software oder Treiber gibt, die als "GA" oder "Gold" veröffentlicht wurde, haben die zuvor maximal eine handvoll Leute oberflächlich getestet, "Gold" sieht für mich anders aus.
Hier sei insbesondere auf die Suchpfadänderung (PATH) verwiesen, welche schnell nicht bestehende Verzeichnisse (\usr\local\bin) dort weit vorn einträgt, was sehr lustige Effekte habe kann.
Ein sicher sinnvoller Hinweis, ebenso, das man selbst vor jeder Änderung ein Backup der Config.sys machen sollte.
Da eine beta 7 von bitwise Firefox in weiter Ferne liegt bzw. momentan überhaupt keine nachvollziehbare Entwiclung mehr stattfindet, sollte man weder auf Ersatz noch Entsatz hoffen.
Sollte als nächstes nicht die "GA" kommen?

Aber auch hier: es spielt keine Rolle in welchem Status der aktuelle Build ist, braucht man einen aktuellen Browser, hat man keine Alternative!
Grüße,

Thorolf

karl
Posts: 7
Joined: Tue 7. Oct 2014, 18:28

Post by karl » Wed 30. Mar 2016, 17:08

Hallo Tom,

ich habe versucht die von Dir genannte Adresse "trac.netlab.org/rpm/#installation" aufzurufen und fand außer einer Datenschutzerklärung nichts.
Frage: was machte ich falsch, oder wo finde ich "rpm" zum herunter laden.

Danke für alle Beiträge. Grossartig!

karl

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Wed 30. Mar 2016, 17:57


aschn
Posts: 690
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Wed 30. Mar 2016, 19:43

Frank Wochatz » Mi 30. Mär 2016, 10:17 wrote: Es ist schon etwas zynisch, auf die Readme.os2 angesichts der Probleme der Benutzer zu verweisen.
Merkwürdig. Hast Du meinen Text nicht verstanden? Ich verweise auf die Datei als Quelle für die erforderlichen RPM-Pakete. Dass ich die Datei mit Link und richtigem Namen noch einmal genannt habe, war nur um Missverständnissen vorzubeugen, nicht mehr und nicht weniger.

Nebenbei, bei der Gelegeheit zu ak120: Seit mindestens 2 Versionen sind die in README.OS2 angegebenen Pakete vollständig. Dein gut gemeinter Hinweis bezieht sich anscheinend auf weit zurückliegende Versionen.
Frank Wochatz » Mi 30. Mär 2016, 10:17 wrote: Egal ob man ZIP oder RPM wählt - man sollte sein System vorab (vorsichtig) aufräumen. Keine der Installationsmethoden nimmt einem diese Arbeit ab.
Nicht ganz. Mit ANPM und der Anleitung von AN für seit längerem schon nicht mehr upgedateten YUM/RPM-Systemen ist das zunächst nicht notwendig. Wegen der CONFIG.SYS-Änderung, dem Voranstellen der \usr-Pfade vor \ecs\dll im LIBPATH, geht es auch ohne. Wichtig ist nur, dass man genau so vorgeht, wie Lewis es in seiner Anleitung beschrieben hat. Dann sollte es blind klappen.

Das man trotzdem irgendwann doppelte Dateien bereinigen sollte, z.B. so, wie Du es beschrieben hast, ist natürlich klar. AFAIR wurde in Foren berichtet, dass ANPM zum Auflisten selbst schon eine einfache Funktion enthält. Das Skript von Jan-Erik Lärka kann ich empfehlen. Aber Vorsicht: Es bennent alle doppelten DLLs um, die im LIBPATH unter \usr\lib und noch woanders gefunden wurden und gibt damit den DLLs aus \usr\lib den Vorzug. Das ganze startet ohne Rückfrage und man sollte die Ausgabe in eine Datei umlenken.

Dem Rest Deines Beitrags stimme ich zu, wenn auch nicht in der heftigen Notwendigkeit, wie Du es geschildert hast. Dazu sollte man noch wissen, dass Du den umständlichen Weg über die ZIP-Dateien und nicht den über ANPM, YUM und RPM gehst. Mit YUM braucht man sich nämlich für einen Teil überhaupt keine Gedanken mehr machen, wobei aber wieder andere, kleinere und seltenere Probleme auftauchen, so wie ich es vorher beschrieben hab.
Andreas Schnellbacher

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Wed 30. Mar 2016, 20:56

Hast Du meinen Text nicht verstanden?
Doch, doch, ich stimme Dir sonst auch komplett zu. :)
Dazu sollte man noch wissen, dass Du den umständlichen Weg über die ZIP-Dateien und nicht den über ANPM, YUM und RPM gehst.
Das stimmt, aber das war nur umständlich, weil es nicht korrekt dokumentiert war (oder ist). Ansonsten ist ein ZIP entpacken sehr einfach. ;)


Was DLLs entfernen mit Scripten angeht, da fallen mir spontan einige Szenarien ein, in denen das garantiert kompliziert wird. Jans Script funktioniert wohl auch nur mit den Libpatheinträgen gem. YUM/RPM. Außerdem gibt es gerade unter eCS diverse unterschiedlichen DLLs mit gleichen Namen, zB. Sprachbibliotheken, und es gibt womöglich sogar DLLs, die im Hintergrund aktiv sind (zB. bei mir). Klar, lösen kann man das alles.

Grundsätzlich würde ich auch für eine OS2 konforme und einheitliche Ablage der DLLs plädieren, statt zur Problemlösung von Dateiduplikaten in zu vielen Libpathlocations (seit eCS) noch mehr Libpathlocations (UNIXROOT) einzuführen. Ist 'ne Designfrage, man kann natürlich auch anfangen alle OS2-User umerziehen zu wollen...

aschn
Posts: 690
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Wed 30. Mar 2016, 21:28

Dazu fällt mir auch dieser scheußliche zusätzliche eCS-Baum ein. Der hat doch nur mehr Nachteile gebracht als die an vielen Stellen schon nicht einheitliche Struktur der OS/2-Verzeichnisse alleine hatte. Wenn die dann wenigstens vieles umsortiert hätten ... - aber einfach nur zusätzliche Verzeichnisse ist natürlich noch schlechter. Da gefällt mir die Idee mit \usr schon besser, auch wenn sie aus der Not der Portierung entstanden ist, selbst wenn das um einiges größer ist.

Das ist nur ein Gedanke dazu. Anderes Thema: Ich bin gespannt, wie sich das ganze mit den AN-OS/2-Versionen entwickeln wird. Sollte dieses Jahr noch eine brauchbare Version erscheinen, würd mich das überraschen. Wahrscheinlich werd ich auch auf die Umsetzung meiner Vorschläge, die IBM-CID-Installation zu ersetzen und bei allen NLS-Versionen einfach nur von der en_US-Version auszugehen noch ewig warten müssen. Genau so wichtig wäre die Möglichkeit ein vorhandenes System ohne Neuinstallation vollständig upgraden zu können. YUM würde es theoretisch möglich machen (bei allen Bedenken, die einem dazu einfallen) - WarpIN nicht und Zips sowieso nicht.
Andreas Schnellbacher

User avatar
ak120
Posts: 900
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Wed 30. Mar 2016, 22:06

Nebenbei, bei der Gelegeheit zu ak120: Seit mindestens 2 Versionen sind die in README.OS2 angegebenen Pakete vollständig. Dein gut gemeinter Hinweis bezieht sich anscheinend auf weit zurückliegende Versionen.
Dann solltest Du beim nächsten Mal (wenn schon verlinkt) auch die letzte Version angeben:
https://github.com/bitwiseworks/mozilla ... README.OS2
Daß die (teilweise) wichtigen Informationen zu fontconfig weiterhin fehlen, möchte ich besser nicht erwähnen. Immerhin hält sich das Rätselraten bei Firefox noch einigermaßen in Grenzen. Ohne orakeln zu müssen, wird sich meine Aussage leider auch auf zukünftige Versionen anwenden lassen.

Das ganze YUM/RPM-System unter OS/2 ist ein einziger Scherbenhaufen, aus dem man sich für den jeweiligen Einsatzzweck erst eine Vase basteln muß.

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Thu 31. Mar 2016, 09:55

Ich glaube die Standpunkte sind klar, wir brauchen jetzt auch nicht in jedem Thread eine Diskussion über die Thematik der Distribution. Laßt mal zum Thema zurückkehren. :)

An Karl: fang einfach mal an, entscheide Dich für eine Installationsmethode, installiere alles und versuche den Browser zu starten. Wenn Dein System nicht zu sehr 'verwachsen' ist, dann wird das ev. auch problemlos funktionieren. Bei Problemen melde Dich wieder.

User avatar
thorolf
Posts: 363
Joined: Wed 25. Dec 2013, 16:14
Location: Rhein-Main

Post by thorolf » Thu 31. Mar 2016, 10:32

Hallo Andreas,

[quote="[url=http://www.os2.org/viewtopic.php?p=5980#p5980]Das ist nur ein Gedanke dazu. Anderes Thema: Ich bin gespannt, wie sich das ganze mit den AN-OS/2-Versionen entwickeln wird. Sollte dieses Jahr noch eine brauchbare Version erscheinen, würd mich das überraschen.[/quote]
ja, so richtig dran glauben mag ich auch noch nicht, aber mal sehen.
Wahrscheinlich werd ich auch auf die Umsetzung meiner Vorschläge, die IBM-CID-Installation zu ersetzen und bei allen NLS-Versionen einfach nur von der en_US-Version auszugehen noch ewig warten müssen.
Du meinst das sie es immer noch nicht kapiert haben, das für den IBM-Weg, jede NLS-Version einzeln zu erstellen, schlichtweg die Ressourcen fehlen???

Mag ja sein, das IBM überhaupt nur dann Support leistet wenn man die alte "CID-Installation" wählt, aber das Problem sollte man sinnvoll umschiffen können. Es ist kaum wahrscheinlich, das ein Fehler auf z.B. einer deutschen Version auftritt, nur weil Oberfläche und Programme eingedeutscht sind, nicht aber bei der ursprünglichen US-Version.
Genau so wichtig wäre die Möglichkeit ein vorhandenes System ohne Neuinstallation vollständig upgraden zu können. YUM würde es theoretisch möglich machen (bei allen Bedenken, die einem dazu einfallen) - WarpIN nicht und Zips sowieso nicht.
DAS sollte bei der Anzahl der zu erwartenden Änderungen für eine neue Version ja wirklich einfach umzusetzen sein.

Einfach alle neuen Treiber und Anwendungen in einem Paket verteilen, am System selbst wird sich ja, wie schon in den vergangenen 10-15 Jahren nichts ändern.
Grüße,

Thorolf

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Thu 31. Mar 2016, 12:37

aschn » Mi 30. Mär 2016, 21:28 wrote: Genau so wichtig wäre die Möglichkeit ein vorhandenes System ohne Neuinstallation vollständig upgraden zu können. YUM würde es theoretisch möglich machen (bei allen Bedenken, die einem dazu einfallen) - WarpIN nicht und Zips sowieso nicht.
Btw, den Satze lese ich jetzt erst, das hat doch garnichts mit den Distributionsmedien oder Techniken ZIP oder RPM zu tun, sondern damit, wie die Sache aufgezogen wird. Ich kann auch mit ZIP eine statische Verzeichnis-Struktur bedienen, oder eine Versionierung mit Warpin machen. Meine USB-Treiber, ACPI, Panorama etc pp. habe ich gerade alle mit ZIP und Warpin aktualisiert, und jetzt sagst Du hier, das geht nicht. Das muß man halt nur richtig anlegen! Wenn natürlich die ZIPs falsch gepackt sind, die Doku wichtige Informationen nicht enthält, dann kann man natürlich schön sagen "Ätsch nimm doch YUM, ist viel einfacher". Das Problem liegt aber überhaupt nicht bei den Formaten oder der Technologie selber. Schwer ist nur, was man nicht weiß.

aschn
Posts: 690
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Thu 31. Mar 2016, 18:26

Das ist leider etwas komplexer: WarpIN fehlt die Möglichkeit Pakete zu deinstallieren.

Mit ZIPs kann man noch nicht mal Skripte ausführen. Dafür müsste man also mindestens zwei Dateien verteilen, wenn man nicht ein externes Installationsprogramm verwenden will.

Einzige Ausnahme ist das Drüberinstallieren. Das geht natürlich mit beiden Methoden

Außerdem geht es mir um eine automatisierte Installation, die möglchst häufig reproduzierbare und supportbare Ergebnisse liefert.
Andreas Schnellbacher

aschn
Posts: 690
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Thu 31. Mar 2016, 18:44

thorolf » Do 31. Mär 2016, 10:32 wrote:
Genau so wichtig wäre die Möglichkeit ein vorhandenes System ohne Neuinstallation vollständig upgraden zu können. YUM würde es theoretisch möglich machen (bei allen Bedenken, die einem dazu einfallen) - WarpIN nicht und Zips sowieso nicht.
DAS sollte bei der Anzahl der zu erwartenden Änderungen für eine neue Version ja wirklich einfach umzusetzen sein.

Einfach alle neuen Treiber und Anwendungen in einem Paket verteilen, am System selbst wird sich ja, wie schon in den vergangenen 10-15 Jahren nichts ändern.
Nein, nicht ganz: Es geht um die Installation einzelner Komponenten, nicht nur um den Austausch von Treiberdateien. Das eCS-Installationsprogramm hat immerhin schon Ableger für die Netzwerkinstallation. Zusätzlich gibt es für ACPI und Grafik diese Warpguide-Wizards. Für Netzwerkdienste und Drucker hat Alex etwas gestrickt.

Davon, auch nach der Erstinstallation einzelne Komponenten an- und abzuwählen ist das noch extrem weit entfernt. In vielen Fällen ist damit eine Neuinstallation der schnellere Weg. Das ist doch völlig unkomfortabel. Ich war überrascht, dass dieser Punkt bereits auf der AN-Feature-Liste steht.
Andreas Schnellbacher

aschn
Posts: 690
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Thu 31. Mar 2016, 19:01

ak120 » Mi 30. Mär 2016, 22:06 wrote: Dann solltest Du beim nächsten Mal (wenn schon verlinkt) auch die letzte Version angeben:
https://github.com/bitwiseworks/mozilla ... README.OS2
Den Link ändere ich gleich in meinem Beitrag.
ak120 » Mi 30. Mär 2016, 22:06 wrote: Daß die (teilweise) wichtigen Informationen zu fontconfig weiterhin fehlen, möchte ich besser nicht erwähnen.
Bei der Installation durch ANPM ist der Unterschied nicht aufgefallen. Da interessieren einen die genauen Dateinamen nämlich nicht mehr. Bei der Installation von Hand fällt man damit natürlich auf'n Bauch. Die weiteren Textänderungen halte ich dagegen für unwichtig. So bekommt man es schon früher oder später mit, dass Webfonts (@font-face) damit doch funktionieren.
Andreas Schnellbacher

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Fri 1. Apr 2016, 10:51

aschn » Do 31. Mär 2016, 18:26 wrote:Das ist leider etwas komplexer: WarpIN fehlt die Möglichkeit Pakete zu deinstallieren.

Mit ZIPs kann man noch nicht mal Skripte ausführen. Dafür müsste man also mindestens zwei Dateien verteilen, wenn man nicht ein externes Installationsprogramm verwenden will.
Das ist auch fast nie wirklich erforderlich (und das ist auch gut so).

Außerdem geht es mir um eine automatisierte Installation, die möglchst häufig reproduzierbare und supportbare Ergebnisse liefert.
Das ist Trade, Standards gegen Support für YUM/RPM.
Im Prinzip hab ich das unter Windows: ich weiß nicht mehr was das System macht. Alles super, solange es funktioniert. Wenn dann doch mal was ist steht man aber so richtig im Regen. Und die haben Millionen User, Tester und Entwicklerhorden.

Und wenn es Probleme gibt wird der Libpath nach rechts geshifted und ein neuer Eintrag hinzugefügt. Astrein.

Andi B.
Posts: 418
Joined: Tue 24. Dec 2013, 16:40

Post by Andi B. » Fri 1. Apr 2016, 11:35

Und wenn es Probleme gibt wird der Libpath nach rechts geshifted und ein neuer Eintrag hinzugefügt. Astrein.
Das ist wirklich nicht elegant. Aber zum Glück können wir das jetzt ja beim REXX OS gleich vom Anfang an richtig machen.

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Fri 1. Apr 2016, 12:23

Andi B. » Fr 1. Apr 2016, 11:35 wrote:
Und wenn es Probleme gibt wird der Libpath nach rechts geshifted und ein neuer Eintrag hinzugefügt. Astrein.
. Aber zum Glück können wir das jetzt ja beim REXX OS gleich vom Anfang an richtig machen.

Haha :)

Zum Glück hat das mit der Programmiersprache jetzt nicht auch noch etwas zu tun. Aber schöne Idee. Der erste Archimedeshatte eine Oberfläche, die komplett in Basic geschrieben war. :)

aschn
Posts: 690
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Fri 1. Apr 2016, 17:16

Frank Wochatz » Fr 1. Apr 2016, 10:51 wrote:
aschn » Do 31. Mär 2016, 18:26 wrote: Das ist leider etwas komplexer: WarpIN fehlt die Möglichkeit Pakete zu deinstallieren.

Mit ZIPs kann man noch nicht mal Skripte ausführen. Dafür müsste man also mindestens zwei Dateien verteilen, wenn man nicht ein externes Installationsprogramm verwenden will.
Das ist auch fast nie wirklich erforderlich (und das ist auch gut so).
Wenn das alles so einfach ist, warum haben sich zunächst Serenity, danach Mensys dann jahrelang hauptsächlich mit der Erstellung eines brauchbaren Installationsprogramms abgegeben?

Ich möchte eine Möglichkeit haben einzelne Komponenten einfach upzugraden oder, z.B. nach Hardwareaustausch so einbinden zu lassen, dass sie funktionieren wie die ursprüngliche Komponente - ohne Gefrickel, sondern einfach mit wiederholtem Ausführen des Installationsprogramms. (Nein, die Upgrade-Variante des aktuellen Mensys-Installationsprogramms meine ich nicht. Das ist nur eine Neuinstallation mit ein paar Sachen, die hinterher auch nicht funktionieren.)
Andreas Schnellbacher

User avatar
Frank Wochatz
Posts: 872
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Fri 1. Apr 2016, 21:14

aschn » Fr 1. Apr 2016, 17:16 wrote:
Frank Wochatz » Fr 1. Apr 2016, 10:51 wrote:
aschn » Do 31. Mär 2016, 18:26 wrote: Das ist leider etwas komplexer: WarpIN fehlt die Möglichkeit Pakete zu deinstallieren.

Mit ZIPs kann man noch nicht mal Skripte ausführen. Dafür müsste man also mindestens zwei Dateien verteilen, wenn man nicht ein externes Installationsprogramm verwenden will.
Das ist auch fast nie wirklich erforderlich (und das ist auch gut so).
Wenn das alles so einfach ist, warum haben sich zunächst Serenity, danach Mensys dann jahrelang hauptsächlich mit der Erstellung eines brauchbaren Installationsprogramms abgegeben?

Gegenfrage: was ist dabei herausgekommen? Wir wie haben sich die Entwicklerressourcen zu damals entwickelt?

aschn
Posts: 690
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Sat 2. Apr 2016, 11:13

Frank Wochatz » Fr 1. Apr 2016, 21:14 wrote:
aschn » Fr 1. Apr 2016, 17:16 wrote: Wenn das alles so einfach ist, warum haben sich zunächst Serenity, danach Mensys dann jahrelang hauptsächlich mit der Erstellung eines brauchbaren Installationsprogramms abgegeben?
Gegenfrage: was ist dabei herausgekommen?
Etwas halbwegs brauchbares, für die lange Zeit aber wohl zu wenig. Außerdem ist das ein fast unwartbares Monstrum geworden. Als Hauptgrund sehe ich das Festhalten an der IBM-CID-Installation.
Frank Wochatz » Fr 1. Apr 2016, 21:14 wrote: Wir wie haben sich die Entwicklerressourcen zu damals entwickelt?
Wenn man es mit den letzten Mensys-Jahren vergleicht, ist es in etwa gleich geblieben. Dmitrij hat wohl mit Abstand den größten Anteil daran und ist seit Gründung von bww noch um einiges aktiver geworden. Mit AN ist die Szene auch noch einmal einen Schub erhalten. So schlecht sieht es gar nicht aus.

Nur so am Rand: Außerdem können wir darüber so viel diskutieren, wie wir wollen, es wird den Weg, den Lewis mit AN geht, nicht übermäßig beeinflussen.
Andreas Schnellbacher