XUL.DLL, mal wieder

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
DonLucio66

XUL.DLL, mal wieder

Beitrag von DonLucio66 »

Ich fahre ArcaOs 2.0.1. Darin enthalten ist ein Firefox 38. Wenn ich den starte, kriege ich einen Fehler:
Couldn't load xul.dll. OS2 error-code=2. Faulty modul nspr4

Ich habe eine einzige Instanz der xul.dll und die liegt im FF-Verzeichnis. Libpath enthält entsprechend den '.'-Eintrag.

Was ich nicht gefunden habe ist ein Modul namens nspr4.

Weiß jemand Rat?
Danke
Don Lucio
Werner.S
Beiträge: 104
Registriert: Mo 23. Dez 2013, 11:29
Wohnort: Nürnberg

Beitrag von Werner.S »

Dir fehlt anscheinend das Paket nspr
yum install nspr müsste reichen.
Die nspr4.dll liegt dann im x:\usr\lib Verzeichnis.
DonLucio66

Beitrag von DonLucio66 »

Ich bin leider an der Installation dieser yum-Infrastruktur gescheitert. Kann man nicht einfach die xul.dll irgendwo runterladen ohne dieses komplexe yum-Brimborium ?

Danke.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hi Don,

man kann alle Pakete auch per Hand installieren, so habe ich das bislang immer unter eCS gemacht. Ist allerdings auch viel Fummelei, es gibt kein komplettes Paket. Bei mir funktioniert das, ev. auch weil ich außer den Browsern eigentlich keine Software benutze, die dieses ganze DLL-Getriebe und den YUM Manager benötigt, dadurch gibt es auch kaum Überschneidungen, ggf muss man Dubletten von DLLs aufspüren.

Unter http://os2news.warpstock.org/Warpzilla.html findest du oben die benötigten Pakete mit Downloadlinks.

Wichtig war bei einigen Paketen auch die korrekte Pfadstruktur ink. Unixrootangabe. Ich musste mir dazu auch eine CMD schreiben, mit der ich FF starte.

M.M. nach wäre es sinnvoll, mal ein Browserkomplettpaket zusammen zu setzen, ev. könnten wir das ja mal heir als Community Projekt gemeinsam machen. Wobei ich jetzt auch VBOX unter Win installiert habe und mich ev. demnächst vom OS2-Browser verabschiede, da ich damit nicht mehr arbeiten kann.

Gruß
Frank
Zuletzt geändert von Frank Wochatz am Sa 12. Mai 2018, 08:27, insgesamt 1-mal geändert.
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Auch ich habe neulich meinem eCS 2.1 den FF38 gegönnt (den letzten Schrei brauch' ich eh nicht...). Hatte alle Info dazu entdeckt und mich dann geschlagen gegeben: zunächst doch ANPM geholt und auf eCS installiert, denn "yum zu Fuß" mag ich mir nicht antun. Allerdings war danach eine Stunde Aufräumen angesagt. Geholfen hat dabei Systemkonfiguration -> eComstation Kernel -> Systempfade (wählen) -> Duplikate, und prüfen und ausmisten. Dabei auch in Warpin (und mehr...) aufgeräumt. Hat anscheinend sauber funktioniert :D Ich hoffe, der Aufwand war nur einmalig und jetzt ist Ruhe...
Für den FF-Start ist schon immer RUN! ganz hilfreich.
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

DonLucio66 hat geschrieben: Sa 12. Mai 2018, 00:40 Ich bin leider an der Installation dieser yum-Infrastruktur gescheitert. Kann man nicht einfach die xul.dll irgendwo runterladen ohne dieses komplexe yum-Brimborium ?

Danke.
Mir ist nicht ganz klar was du erreichen willst. Weil in Arcaos ist yum ja eh schon vorhanden und sauber installiert.
Es ist ja auch ANPM vorhanden was ein GUI zu yum ist.
Wieso nicht mit dem das ganze updaten? Und vorallem ist es sehr merkwürdig dass der 38 nicht direkt läuft. Weil so viel ich weiss müsste alles was der braucht auch installiert sein.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

DonLucio66 hat geschrieben: Fr 11. Mai 2018, 17:29 Ich fahre ArcaOs 2.0.1. Darin enthalten ist ein Firefox 38.
Firefox 38 sollte man es besser nicht nennen. Es handelt sich um inoffizielle Private Builds, welche irrtümlich ein falsches Branding verwenden.
Wenn ich den starte, kriege ich einen Fehler:
Couldn't load xul.dll. OS2 error-code=2. Faulty modul nspr4

Ich habe eine einzige Instanz der xul.dll und die liegt im FF-Verzeichnis. Libpath enthält entsprechend den '.'-Eintrag.
Und welchen Wert hat MOZ_NO_REMOTE in der Umgebung?
Was ich nicht gefunden habe ist ein Modul namens nspr4.

Weiß jemand Rat?
So verwende man einfach die Zip-Archive, welche auf http://os2news.warpstock.org/Warpzilla.html bereitstehen - unterhalb von "Test Versions". Ist zwar bzgl. fontconfig auch mit etwas Ballast verbunden, aber sollte schneller auszumisten sein als der ganze Schmer mit den zusammengewurstelten RPM-Paketen.
DonLucio66

Beitrag von DonLucio66 »

_diver hat geschrieben: Sa 12. Mai 2018, 10:14Und vorallem ist es sehr merkwürdig dass der 38 nicht direkt läuft. Weil so viel ich weiss müsste alles was der braucht auch installiert sein.
Stimmt. Ursprünglich lief der FF 38 auch prima. Bis ich einen Crash meiner WPS hatte und ein Archiv restoren musste. Dabei ist offenbar irgendwas verschütt gegangen.
Gruß
Don Lucio
Don Lucio

Beitrag von Don Lucio »

Frank Wochatz hat geschrieben: Sa 12. Mai 2018, 08:26Unter http://os2news.warpstock.org/Warpzilla.html findest du oben die benötigten Pakete mit Downloadlinks.
Finde dort nur Komplettpaket FF 45.9.0. Und darin sind auch keine der benötigten ns???.dll enthalten.

Frank Wochatz hat geschrieben: M.M. nach wäre es sinnvoll, mal ein Browserkomplettpaket zusammen zu setzen
Das wäre in der Tat *SEEEHR* sinnvoll ...

Ich werde mal weiter (ver)suchen.

Gruß
Don Lucio.
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Frank Wochatz hat geschrieben: M.M. nach wäre es sinnvoll, mal ein Browserkomplettpaket zusammen zu setzen
Don Lucio hat geschrieben: Das wäre in der Tat *SEEEHR* sinnvoll ...
Dazu hab ich zwei passende Antworten -
1) Das existiert ja eh schon seit einer Weile - yum richtig füttern laut Readme oder ANPM. Und alles läuft. Oder -
2) Wenn du damit meinst ein komplett Archiv mit allen dlls die zum Zeitpunkt des bauens von FF38 aktuellDon Lucio waren, ganz klar nein. Das wäre nicht sinnvoll, sondern endet in einer Katastrophe. Gerade weil auf diversen Installationen verschiedene dlls in unterschiedlichen Versionen mehrfach vorhanden sind, ist das Problem. Dieses zu beheben geht am Besten mit yum bzw. ANPM und den rpm Paketen. Und dem richtigen LIBPATH.

Bei einem neu installierten ArcaOS bzw. bei einem mit ANPM aufgerüstetem System, braucht man nur noch den .; im Libpath weiter nach hinten schieben und alle Standardanwendungen laufen. Das händische kontrollieren auf doppelte dlls in verschiedenen Verzeichnissen, schafft keiner mehr fehlerlos ohne rpm/yum/ANPM Unterstützung. Wer's versucht, macht sich selbst das Leben unnötig schwer.
Zuletzt geändert von Andi B. am Sa 12. Mai 2018, 21:09, insgesamt 1-mal geändert.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Es ist halt die Frage, ob man selber noch wissen will was auf dem Rechner los ist oder nicht. Da ich hier Benutzer, Installateur und Admin in einer Person bin, bevorzuge dich die manuelle Installation. Bastelei war das eigentlich auch immer nur, weil die Installation nicht so gut bis gar nicht dokumentiert ist, und man sich die ganzen einzelnen Pakete zusammen suchen musste, und dann noch die Verzeichnisstruktur recherchiert, angelegt und im Environment verfügbar gemacht werden muss.

Probleme mit doppelten DLLs hatte ich bislang eigentlich erst einmal, und das lag an meiner eigenen Blödheit, bzw. auch ein bissel daran, dass eCS einige Verzeichnisse doppelt hat, die eigentlich den gleichen Inhalt haben (zB. mehrere Verzeichnisse für System DLLs), und ich Fehler bei der Installation gemacht hatte.

Welche Pakete man benötigt, und wie die Verzeichnisstruktur aussehen muss, das sollte eigentlich dem Entwickler bekannt sein, denn irgendjemand legt ja auch die YUM/RPM Archive an, und baut diese Informationen dort ein. Es würde die Sache stark vereinfachen, wenn man sich da nicht in Schweigen hüllen würde. Dann könnte jeder für sich selbst entscheiden, wie er installiert. Auf mich wirkt es leider so, dass YUM/RPM mit der Brechstange durchgedrückt werden sollen. Das hat schon fast etwas Ideologisches.

Wenn man Non-YUM Installtionen nicht supporten möchte, könnte man dies ja weiterhin sein lassen. Mit einer Dokumentation würden sich allerdings auch etliche der Fehler, mit denen man sich verständlicherweise aus Zeitgründen nicht beschäftigen möchte gar nicht erst entstehen.
Zuletzt geändert von Frank Wochatz am So 13. Mai 2018, 11:07, insgesamt 2-mal geändert.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Welche Pakete man benötigt, und wie die Verzeichnisstruktur aussehen muss, das sollte eigentlich dem Entwickler bekannt sein, denn irgendjemand legt ja auch die YUM/RPM Archive an, und baut diese Informationen dort ein. Es würde die Sache stark vereinfachen, wenn man sich da nicht in Schweigen hüllen würde. Dann könnte jeder für sich selbst entscheiden, wie er installiert. Auf mich wirkt es leider so, dass YUM/RPM mit der Brechstange durchgedrückt werden sollen. Das hat schon fast etwas Ideologisches.
Ich sehe das ein bißchen anders. Vielleicht deshalb, weil ich selbst auch bei vielen Projekten mit entwickle. Dass jemand sich "in Schweigen hüllen" würde, denke ich nicht. Ich weiß wieviel Zeit ich selbst in das Schreiben und updaten der Readmes stecke. Trotzdem kann man nicht alles so beschreiben, dass alle zufrieden sind.

Und es kann nach wie vor jeder selbst entscheiden wie er installiert. RPM ist ja auch nur ein Archiv. Wie man so eines entpackt, steht auch auf den wiki Seiten beschrieben. Und diese Doku finde ich gar nicht schlecht. Man könnte sogar soweit gehen und sagen, wer die Abhängigkeiten und Mindestversionen genau wissen will, der kann ja einfach das RPM lesen. Warum soll ein Entwickler das Gleiche noch ein zweites Mal in anderer Textform beschreiben?

YUM/RPM sehe ich nicht ideologisch, sondern rein pragmatisch. Es ist schlicht für 99,99% der User (natürlich inklusive mir) nicht mehr möglich alle Abhängigkeiten der verschiedenen Programme voll zu durchblicken und händisch alles auf Stand zu halten. So viel Zeit hab ich nicht. Bei Win geht das schon lange nicht (und ist dort ja gar nicht gewollt, bzw. sogar bewußt unmöglich gemacht), bei Linux theoretisch möglich aber praktisch auch schon lange nicht mehr, und bei OS/2 geht's halt auch theoretisch (alles ist ja nachlesbar wenn man will) aber praktisch auch nicht mehr. Zumindest dann nicht, wenn man mehrere moderne Anwendungen haben und diese auch manchmal updaten will.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Vor diesem Hintergrund stellt sich für mich die Frage, ob die Haltung sich gegen eine automatisierte, im Dateiergebnis aber unübersichtliche, Installation zu wehren, nicht die viel ideologischere ist.
Andreas Schnellbacher
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Frank Wochatz hat geschrieben: So 13. Mai 2018, 11:06 Wenn man Non-YUM Installtionen nicht supporten möchte, könnte man dies ja weiterhin sein lassen. Mit einer Dokumentation würden sich allerdings auch etliche der Fehler, mit denen man sich verständlicherweise aus Zeitgründen nicht beschäftigen möchte gar nicht erst entstehen.
Entwickler und Dokumentierer, das waren doch schon immer zwei disjunkte Universen :mrgreen:

Bestimmt wird es auch in Zukunft (hoffentlich) "jede Menge" neue Software für uns geben, die sich aus einem einfachen zip, mit darin einer exe und vielleicht wenigen non-standard-dlls und evEntuell einer Doku, nach Gusto installieren lässt. Wo eine Software aber komplexer wird, modern stark modularisiert mit obendrein Versionsabhängigkeiten, kommt man um Standards nicht herum. Das halte ich nicht für Ideologie, sondern basiert auf praktischer Erfahrung auch aus'm Ex-Job: Support-Möglichkeit auf Entwickler- und Admin-Seite, besserer Überblick und Vertrauen auf Benutzerseite. Erst recht, wenn sogar Security eine Rolle spielt. Und für den einen oder anderen vielleicht sogar sowas wie "IT-Profi-Ethos", für viele (wie mich...) das Prinzip "1 Click und läuft". :geek:

Auf unserer Plattform mit uns paar verbliebenen Userln (und Selbst-Adminseln) :) lässt es sich da gut "liberal" sein, woanders läuft alles erst duch ein _zentrales_ Konfigurations- und Qualitätsmanagement mit strikten Konventionen. Dicke Bücher zum Thema haben aber andere besser(?) geschrieben :)
Nun mag einer noch das "Wie-genau" anders beurteilen, als gerade praktikabel etabliert. NIH-Syndrom ("not invented here"), nix Schlimmes :evil:
Probleme mit doppelten DLLs hatte ich bislang eigentlich erst einmal, und das lag an meiner eigenen Blödheit, bzw. auch ein bissel daran, dass eCS einige Verzeichnisse doppelt hat, die eigentlich den gleichen Inhalt haben (zB. mehrere Verzeichnisse für System DLLs), und ich Fehler bei der Installation gemacht hatte.
_Das_ ging ja nu' gar nicht! Willkommen im Club... :lol:
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

aschn hat geschrieben: So 13. Mai 2018, 12:48 ...gegen eine automatisierte, im Dateiergebnis aber unübersichtliche, Installation zu wehren...
Gegen _Un_übersichtliches würde ich aber mitmachen :roll:

Edit: "Unübersichtlich" würde ich's nicht nennen, "von außen nicht unmittelbar nachverfolgbar" meinetwegen :)
Im Datei_ergebnis_ kommt aber alles nach einer standardisierten "Wo"-Konvention zu liegen, und ANPM zeigt mir eine zentrale Übersicht des "Was". Im Prinzip, und soweit es auch die "Führung" bekommen kann.
- In Anfangstagen hatte ich mir fleißig in einer txt-Datei notiert, was ich wann mit welcher Version installiert hatte... _Der_ Eifer blieb natürlich recht endlich, wie sich jeder denken kann ;)
Zuletzt geändert von LotharS am So 13. Mai 2018, 15:01, insgesamt 1-mal geändert.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

aschn hat geschrieben: So 13. Mai 2018, 12:48 Vor diesem Hintergrund stellt sich für mich die Frage, ob die Haltung sich gegen eine automatisierte, im Dateiergebnis aber unübersichtliche, Installation zu wehren, nicht die viel ideologischere ist.
Die Installation ist auf beide Weisen möglich: manuell oder automatisch mit yum. Ich finde es nicht ideologisch, sich eine der beiden Möglichkeiten auszusuchen oder aussuchen zu dürfen. Eine der beiden Möglichkeiten durchzudrücken indem man die notwendigen Infos nicht mehr weiter gibt aber schon.

Gut, Andi B. Einwand, dass man die Pakete analysieren könnte lasse ich gelten. Könnte man machen.

Offenbar gibt es auch weiterhin Interesse an einer manuellen Installation, da bin ich wohl nicht der einzige. Warum sollte man die Leute / uns unterstützen? Es gibt sicherlich keinen richtigen Grund dazu, wie es auch keinerlei Grund gibt überhaupt freie Software raus zugeben. Das funktioniert natürlich nur mit gutem Willen.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Frank Wochatz hat geschrieben: So 13. Mai 2018, 15:15 Eine der beiden Möglichkeiten durchzudrücken indem man die notwendigen Infos nicht mehr weiter gibt aber schon.
Das hört sich so an, als würde diese Info bei bww so nebenbei abfallen und irgendwo rumliegen und es nur an den bösen Entwicklern liegt, dass sie diese Info zurückhalten. (Das wäre dann genauso ideologisch, wie es von anderen einzufordern.) Das ist natürlich nicht der Fall. Entwickler wissen häufig selbst nicht zuverlässig, welche Pakete und Versionen sie im einzelnen installiert haben. (Die Mozilla-Entwicklungsumgebung ist noch um einiges heftiger als der UNIXROOT-Baum für einen Client-Rechner.)

Deshalb müssen das Entwickler, bevor sie solche Info verlässlich herausgeben, vorher auf frischen Systemen testen. Und da kann ich mich daran erinnern, dass bww verkündet hat, dass ihnen dazu die Zeit fehlt. Dafür liefern sie aber eine reproduzierbare Möglichkeit, wie man auf einem frischen System das Produkt installiert bekommt (hat Lothar schon angesprochen). Das ist doch gar nicht so schlecht.
Frank Wochatz hat geschrieben: So 13. Mai 2018, 15:15 Gut, Andi B. Einwand, dass man die Pakete analysieren könnte lasse ich gelten. Könnte man machen.

Offenbar gibt es auch weiterhin Interesse an einer manuellen Installation, da bin ich wohl nicht der einzige. Warum sollte man die Leute / uns unterstützen?
Das sollte wirklich genau so gehen: Inhalt der benötigten Pakete auspacken oder auflisten, DLLs und Zusatzdateien solange verschieben, bis Mozilla startet. Anleitung schreiben. Auf möglichst vielen Systemen testen.

Ich würd das nur nicht von bww einfordern. Statt dessen können das Leute mit viel Zeit machen.
Andreas Schnellbacher
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Also, wenn "Vermeiden von Doppel- und Mehrfacharbeit" als Ideologie bezeichnet wird, trete ich der sofort bei :P
Gilt für mich als einfacher User hier, als gewiss auch für den schlaueren Entwickler am anderen Ende. Würde ich aber lieber als "Zeitmanagement" (und "Geld-") bezeichnen, um die Keule "methodisches Software-Management" mal stecken zu lassen. So theoretisch mag ich sonst gar nicht, ich probier' lieber aus. 8-)

@Don Lucio: Dir ist - abseits des Disputs - hoffentlich längst geholfen, od'r? :)
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

"Einfordern" ist ein großes Wort, was ja auch irgendwie gleich wieder den schwarzen Peter zuteilt. Ich sag hier mal was ich besser finde würde, ich hoffe das ist noch erlaubt. Wenn hier Meinungen und Kritik unerwünscht sind, sagt Bescheid. Ich hoffe ansonsten doch schon, dass der Entwickler weiß, auf welche Bibliotheken er zurückgreift. Aber wir können uns die weitere Diskussion hier Mangels Zielführung auch gerne sparen.

Don, ich hoffe du bekommst dein DLL Problem irgendwie in den Griff. Ich kann dir leider nicht helfen, als auf o.g. Links zu verweisen, in irgendeinem Paket wird die entsprechende DLL drin sein.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

"Einfordern" ist ein großes Wort, was ja auch irgendwie gleich wieder den schwarzen Peter zuteilt. Ich sag hier mal was ich besser finde würde, ich hoffe das ist noch erlaubt. Wenn hier Meinungen und Kritik unerwünscht sind, sagt Bescheid.
Ich tu mir schwer mit solchen Aussagen Frank. Bei mir kommen einige deiner Äußerungen hier plakativ formuliert so rüber -
- Jemand (wer denn eigentlich?) will dich zwingen yum/rpm zu verwenden
- du willst das nicht (ist ja okay)
- die Entwickler sind deiner Meinung nach zu faul zusätzlich mindestens eine zweite (was darfs denn sein, zips oder wpis oder FeatureInstaller, ...) Installationsart anzubieten und auch zu faul das alles in Prosa leicht verständlich für Jedermann niederzuschreiben. (Es wurde hier aber auch schon indirekt angemerkt, dass das mit so manchen Monsterprojekten gar nicht mehr geht weil die Welt eben komplizierter geworden ist.)
- die rpm Verweigerer (hier in diesem thread konkret du) ihrerseits sind allerdings auch zu faul die rpms zu entpacken und die darin festgehaltenen Installationsregel und Abhängigkeiten zu lesen. Geschweigen denn davon eine andere, genehmere Installationsart zusammenzupacken, mehr ist es ja nicht ;) und diese zu testen.
- wenn man all dies hier versucht höflich (und nicht so rüde wie ich jetzt) zu argumentieren und rüberzubringen, dann kommt von dir das Totschlagargument - deine Meinung und Kritik sind unerwünscht und deshalb argumentierst du nicht mehr, sondern ziehst dich schmollend zurück.

Sorry wenn ich so direkt bin, aber es ist mein letztes Post in diesem thread. Vielleicht bin ich einfach zu alt und reagiere zunehmend aggresiver auf solche Haltungen, oder es gibt wirklich immer mehr Leute, die zwar theoretisch alles besser wissen und dieses ihr vermeintliches Wissen immer lauter rausposaunen, aber praktisch dann doch unfähig oder zu faul sind ihre Theorien in die Praxis umzusetzen. Konkret kritisiere ich, dass keiner von den rpm/yum Verweigerern, selbst eine bessere Installationsmethode anbieten und solche immer wieder nur von anderen zu gefordert wird.

Hast du bessere Möglichkeiten anzubieten wie man AOO, FF, SM, Thunderbird, Sunbird, LuckyBackup, KeepassX, QT-Designer, KDiff3, PSI, qpdfview, MP3-Diags, QGit, cups mit dazupassenden ghostscript, .... parallel ans laufen bringt, dann pack' es zusammen, teste es unter verschiedensten Konfigurationen, setze Bugtracker auf und hilf den Leuten wenns trotzdem klemmt, veröffentliche es mit guter Beschreibung, und dann werde auch ich anfangen zu testen ob es wirklich einfacher und besser als yum/rpm/ANPM ist.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

"Entwicker zu faul" und " von den Entwickler "einfordern" sind Worte, die ihr mir gerade in den Mund legt und nicht ich gesagt habe. Ich halte den Entwicker nicht für faul, ganz im Gegenteil. Ich denke allerdings, dass hier ein Tech mit der Brechstange durchgedrückt werden soll. Ich denke, dass es tatsächlich kein Problem wäre, mal den DLL Tree mit den Versionen anzugeben, das würde für denjenigen, der den Tree eh erstellt bzw. im Blick haben muss sicherlich keine abendfüllende Veranstaltung. Klar, man kann sich jetzt als Außenstehender in die RPMs einarbeiten, das ist sicherlich richtig. Wir können ja mal eine Spendenaktion dafür starten, ev. macht es jemand.
Andi B. hat geschrieben: Mo 14. Mai 2018, 08:45 Konkret kritisiere ich, dass keiner von den rpm/yum Verweigerern, selbst eine bessere Installationsmethode anbieten und solche immer wieder nur von anderen zu gefordert wird.
Wie wäre es mit einem ZIP Archiv, wo die Sachen drin sind.
Zuletzt geändert von Frank Wochatz am Mo 14. Mai 2018, 09:23, insgesamt 1-mal geändert.
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

Frank Wochatz hat geschrieben: Mo 14. Mai 2018, 09:18 Wie wäre es mit einem ZIP Archiv, wo die Sachen drin sind.
Hallo zusammen

ich denke ich muss kurz einige Sachen anbringen. Jedes rpm gibt es auch als zip. Das heisst für Leute, die kein rpm wollen, dir können das ZIP nehmen und es installieren. Was es nicht gibt (und von uns auch nicht geben wird), sind komplett ZIP's für eine Anwendung. Sprich ein ZIP wo wir alles hineinpacken das es braucht. Es ist nicht, dass wir zu faul sind dazu, sondern dass und schlicht die Zeit bzw. das Geld dazu fehlt. Weil das ganze wäre ein händisches zusammensuchen (zusammen Zippen). Die aktuellen ZIP's sind ein Extrakt aus den rpm halt als ZIP gepackt.
Und ja wir sind überzeugt von rpm, weil es für Otto Normalverbraucher eine Installation sehr einfach macht. Vorallem seit ANPM.

Dass nicht jedermann/frau rpm lieben tut/muss, ist und klar. Und genau für die sind dann halt die ZIP's. Wobei man sich auch da an die vorgegebene Struktur halten sollte. Wenn man das nicht tut, kann es halt sein dass einiges nicht geht. Weil wir testen und supporten nur die vorgegebene rpm Struktur.

Da dieser Thread eh schon nichts mehr mit dem "XUL.dll mal wieder" zu tun hat, denke ich sollte man einen neuen starten oder diesen ausgliedern.
Benutzeravatar
Helmut Bu
Beiträge: 46
Registriert: Mo 6. Jan 2014, 14:02
Wohnort: Reutlingen

Beitrag von Helmut Bu »

Frank Wochatz hat geschrieben: Mo 14. Mai 2018, 09:18 Wie wäre es mit einem ZIP Archiv, wo die Sachen drin sind.
Es gibt doch eine aktuelle ZIP-Version von Dave Yeo (FF 45.9.0 - 20180423).
Die läuft bei mir prima "out of the box":
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Helmut Bu hat geschrieben: Mo 14. Mai 2018, 18:15 Es gibt doch eine aktuelle ZIP-Version von Dave Yeo
Die enthält nicht die DLLs.
Andreas Schnellbacher
Antworten