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

Post by DonLucio66 » Fri 11. May 2018, 17:29

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
Posts: 86
Joined: Mon 23. Dec 2013, 11:29
Location: Nürnberg

Post by Werner.S » Fri 11. May 2018, 22:58

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

DonLucio66

Post by DonLucio66 » Sat 12. May 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.

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

Post by Frank Wochatz » Sat 12. May 2018, 08:26

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
Last edited by Frank Wochatz on Sat 12. May 2018, 08:27, edited 1 time in total.

User avatar
LotharS
Posts: 481
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Sat 12. May 2018, 08:55

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
Posts: 131
Joined: Fri 27. Jun 2014, 10:57

Post by _diver » Sat 12. May 2018, 10:14

DonLucio66 wrote:
Sat 12. May 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.

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

Post by ak120 » Sat 12. May 2018, 10:15

DonLucio66 wrote:
Fri 11. May 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

Post by DonLucio66 » Sat 12. May 2018, 13:25

_diver wrote:
Sat 12. May 2018, 10:14
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.
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
Posts: 1
Joined: Fri 11. May 2018, 17:18

Post by Don Lucio » Sat 12. May 2018, 19:08

Frank Wochatz wrote:
Sat 12. May 2018, 08:26
Unter 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 wrote: 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.

User avatar
LotharS
Posts: 481
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Sat 12. May 2018, 20:23


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

Post by Andi B. » Sat 12. May 2018, 20:54

Frank Wochatz wrote: M.M. nach wäre es sinnvoll, mal ein Browserkomplettpaket zusammen zu setzen
Don Lucio wrote: 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.
Last edited by Andi B. on Sat 12. May 2018, 21:09, edited 1 time in total.

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

Post by Frank Wochatz » Sun 13. May 2018, 11:06

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.
Last edited by Frank Wochatz on Sun 13. May 2018, 11:07, edited 2 times in total.

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

Post by Andi B. » Sun 13. May 2018, 11:45

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.

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

Post by aschn » Sun 13. May 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.
Andreas Schnellbacher

User avatar
LotharS
Posts: 481
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Sun 13. May 2018, 13:34

Frank Wochatz wrote:
Sun 13. May 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:

User avatar
LotharS
Posts: 481
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Sun 13. May 2018, 13:51

aschn wrote:
Sun 13. May 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 ;)
Last edited by LotharS on Sun 13. May 2018, 15:01, edited 1 time in total.

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

Post by Frank Wochatz » Sun 13. May 2018, 15:15

aschn wrote:
Sun 13. May 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.

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

Post by aschn » Sun 13. May 2018, 20:44

Frank Wochatz wrote:
Sun 13. May 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 wrote:
Sun 13. May 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

User avatar
LotharS
Posts: 481
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Sun 13. May 2018, 22:12

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? :)

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

Post by Frank Wochatz » Sun 13. May 2018, 23:59

"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.
Posts: 402
Joined: Tue 24. Dec 2013, 16:40

Post by Andi B. » Mon 14. May 2018, 08:45

"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.

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

Post by Frank Wochatz » Mon 14. May 2018, 09:18

"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. wrote:
Mon 14. May 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.
Last edited by Frank Wochatz on Mon 14. May 2018, 09:23, edited 1 time in total.

_diver
Posts: 131
Joined: Fri 27. Jun 2014, 10:57

Post by _diver » Mon 14. May 2018, 09:53

Frank Wochatz wrote:
Mon 14. May 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.

User avatar
Helmut Bu
Posts: 43
Joined: Mon 6. Jan 2014, 14:02
Location: Reutlingen

Post by Helmut Bu » Mon 14. May 2018, 18:15

Frank Wochatz wrote:
Mon 14. May 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/

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

Post by aschn » Mon 14. May 2018, 18:35

Helmut Bu wrote:
Mon 14. May 2018, 18:15
Es gibt doch eine aktuelle ZIP-Version von Dave Yeo
Die enthält nicht die DLLs.
Andreas Schnellbacher