Hallo,
für das Modul das ich aktuell entwickle (Signalbot) habe ich ein install script, welches u.a ein Paket von github runterlädt und installiert.
Obwohl das größtenteils Java ist, sind leider 1 (bald 2) native Libraries dabei, und zwar nur für Linux x86.
Für arm (Raspberry) muss man die selber übersetzen, was für viele User ein Problem darstellen könnte.
Daher hab ich die libs jetzt auf meine eigene Homepage gestellt und lade diese mit "wget" nach.
Ich würde sie aber lieber auf einen Server im FHEM context stellen. Haben wir da was und wie komme ich da dran?
Danke,
Jörg
Unter welcher Lizens stehen denn die 2 native Libraries?
Theoretisch könnte ich mir vorstellen das diese bei passender Lizenz ins SVN geladen werden könnten.
Alles GPL
Jörg
Ich denke mit einem entsprechenden Verweis auf die Githubseite sollte das kein Problem sein.
Schauen wir mal was die anderen sagen.
Im Zweifelsfall in ./contrib ablegen, das hat den Vorteil, dass das Modul in FHEM svn liegt und man zumindest einen direkten Link zur Datei erzeugen kann, der dann auch auf das FHEM repository zeigt. Das mit dem Link könnte hilfreich sein, weil der contrib Ordner nicht per normalem FHEM Update aktualisiert wird.
Andererseits habe ich keine Regel gefunden, die das Ablegen von anderen als perl-Dateien im ./lib Verzeichnis untersagen würde.
Hauptsache, der Code ist offengelegt und die Lizenz passt.
SVN und andere Versionskontrollsysteme sind eigentlich nicht für Binaries gedacht. Wenn ich da regelmäßig Updates mache, könnte das das Repository ganz schön aufblähen.
Und dann fließt es ins fhem.tar.gz mit ein - gerade ausprobiert - das geht dann gleich von 27MB auf 28MB hoch. Wenn das mehr machen ....
Besser wäre es m.E. auf fhem.de ein Download Verzeichnis zu haben haben, auf das man per ftp Dateien hochladen kann.
Da hole ich das dann per wget aus dem Script. Das Verzeichnis muss nicht mal auflistbar sein solange das Script dann von dort Downloaden kann.
Aber das würde natürlich einen ftp Zugang auf fhem.de erfordern, den wahrscheinlich nur handverlesene Leute haben.
Gruß,
Jörg
FTP hat soweit mir bekannt niemand. Würde auch kein Sinn machen, da FTP tot ist. Es gibt bessere und sicherere Methoden files zu transferieren.
FTP, scp, .. - war für mich jetzt einfach Synonym für ein file transfer Protokol. Holen will ich ja sowieso über http (wget).
Wenn es z.B. ein Verzeichnis auf fhem.de gäbe, auf das ich mit meinem SVN key per scp Dateien stellen kann (aber außerhalb von SVN) wäre das z.B. eine kontrollierte und sichere Methode dafür. Da aber sicher nicht jeder vollen ssh Zugang haben sollte, stellt sich dann die Frage wie man aufräumt und wie man das konfiguriert.
Jörg
Wir haben unlaengst beschlossen, Third-Party Bibliotheken aus FHEM zu entfernen, aus diversen Gruenden (Lizenz-Problem, Pflege fuer diverse Architekturen, kein Update, sinnloses Duplizieren, etc) Obwohl der Vorgang nicht mit Hochdruck verfolgt wird, neue "Aufgaben" reinzuholen sollte nicht mehr passieren.
Ich kann die Argumentation zwar nachvollziehen (es gibt nur Quellcode, Binaries zu bauen ist muehselig), bin aber noch nicht sicher, ob sie dann etwas aufgeweicht nicht fuer alles anwendbar ist: cpan/apt/etc zu bedienen ist muehselig, hab NAS/docker/etc, da geht es nicht, usw, FHEM-update ist viel einfacher.
Wenn ein Konsens gefunden wird, dass hier eine Ausnahme gemacht werden soll: Neben SVN einen weiteren Weg zu etablieren ist muehselig (Software muss installiert, Firewall umkonfiguriert, Authorisierungen muessen uebernommen, oder wenn nicht moeglich, neu eingeholt werden). Eher wuerde ich ein neues Verzeichnis in SVN anlegen (bitte um einen Namen), was weder Teil der .tar.gz ist, noch per FHEM-update verteilt wird.
Zitat von: rudolfkoenig am 05 Februar 2021, 09:28:43
Eher wuerde ich ein neues Verzeichnis in SVN anlegen (bitte um einen Namen), was weder Teil der .tar.gz ist, noch per FHEM-update verteilt wird.
Vorschlag für Namen: ./thirdparty/
Darunter legt jeder Entwickler, der dort was bereitstellt, ein Unterverzeichnis mit seinem Nickname an.
In diesem Ordner hat der Entwickler dann auch die für seine Bereitstellung zugehörige Lizenz als Datei mit abzulegen, zumindest aber ein readme mit einer URL zur gültigen Lizenz.
Dieser Vorschlag ist von mir aus OK, aber das ist fuer mich noch kein "Konsens", wenigstens der Thema-Ersteller sollte melden, ob das akzeptabel ist. Sonst hockt das Verzeichnis nur verwaist rum.
Hi Rudi,
ja ist ok für mich. Darin dann lieber ein Verzeichnis des Users (also Adimarantis) oder des Moduls (Signalbot) ?
Zugriff sollte dann ja mit
wget https://svn.fhem.de/fhem/trunk/fhem/thirdparty/Adimarantis/<dateiname>
gehen.
Gruß,
Jörg
Zitat von: Adimarantis am 07 Februar 2021, 14:39:26
Darin dann lieber ein Verzeichnis des Users (also Adimarantis) oder des Moduls (Signalbot) ?
Der Vorschlag mit dem Username kam von mir deshalb, weil es auch Developer geben soll, die mehr als ein Modul betreuen.
Somit wären die Verantwortlichkeiten eindeutig geklärt.
Du kannst ja in "Deinem" Ordner dann immer noch einen Unterordner mit Deinem Modulnamen anlegen.
Das Problem mit dem Usernamen ist, dass es doof ist, wenn das Modul weitervererbt wird.
Das Problem mit dem Modulnamen ist, dass es doof ist, wenn mehrere Module es verwenden.
Ich schlage ein Verzeichnisnamen vor, der das Gespeicherte beschreibt (z.Bsp. libXYZ), und ein README da drin, wo der Rest drin steht: Lizenz, welches Modul braucht es, warum muss das Ding unbedingt hier gespeichert sein, wer betreut es.
Fuers Protokoll: ich fuehle mich immer noch unwohl, weil es de-facto ein Rueckkehr von dem ist, was wir beschlossen haben.
Zitat von: rudolfkoenig am 07 Februar 2021, 20:29:42
Fuers Protokoll: ich fuehle mich immer noch unwohl,
Richtig gut finde ich das Vorhaben auch nicht. Zumal es schwer zu dokumentieren ist und ich beim Stöbern auf der FHEM Webseite keine passende Stelle finden konnte, an der eine Beschreibung dieses technischen Vorhabens sinnvoll unterzubringen wäre. Natürlich ist es in erster Linie ein Feature, das aus Sicht von Entwicklern vielleicht Sinn macht. Aber aus Sicht eines "normalen" Anwenders werden die Bezugsmöglichkeiten von für FHEM-Modulen benötigten Dateien und die damit verbundenen Mechanismen immer unübersichtlicher.
Würde es hier eine Umfrage zu dem Thema geben, ob man das wirklich umsetzen soll, würde ich vermutlich mit Nein stimmen.
Eure Entscheidung.
Ich könnte es auch auf mein github legen, wenn das sonst zu viele Bauchschmerzen macht.
Falls es allerdings mal ein offizielles Modul werden sollte (und das Nutzerfeedback ist sehr aktiv), dann wäre es gut die Abhängigkeiten zu externen Quellen zu minimieren. Es wird allerdings ohnehin ein externes Paket benötigt, welches ich (da ja verfügbar) nicht nochmal kopieren würde.
Ist so ein Modul überhaupt im Standard erwünscht, das Standalone nicht funktionieren kann (und die Installation auch nicht aus FHEM anstoßen kann, da mit root und nur Linux)?
Siehe aktuellen Stand dazu:
https://forum.fhem.de/index.php/topic,118370.0.html
und
https://wiki.fhem.de/wiki/Signalbot
Jörg
Zitat von: Adimarantis am 08 Februar 2021, 13:27:01
Ist so ein Modul überhaupt im Standard erwünscht, das Standalone nicht funktionieren kann (und die Installation auch nicht aus FHEM anstoßen kann, da mit root und nur Linux)?
Jörg
Hallo Namensvetter,
mir fallen mindestens das echodevice Modul ein, das ohne eigene NPM Modul nicht auskommt. Hier wird für die Installation ein temorärer Fhem User mit höheren Rechte definiert. Schau Dir doch mal die Installationsanleitung hierzu an. https://mwinkler.jimdo.com/modul-echodevice-npm/
Grüße Jörg
Zitat von: Adimarantis am 08 Februar 2021, 13:27:01
Ist so ein Modul überhaupt im Standard erwünscht, das Standalone nicht funktionieren kann (und die Installation auch nicht aus FHEM anstoßen kann, da mit root und nur Linux)?
Naja, wir haben mit Echo Device, Nmap, Speedcheck etc. ja auch einige weitere Module, die nur funktionieren, wenn auf dem System weitere Software (eben z.B. nmap, speedcheck-cli, NodeJS) installiert wurde. Dabei reicht die Unterstützung von "Das Modul installiert npm-Module mit ein paar Klicks" bis zu einem Eintrag in der CRef.
Für meinen Geschmack sollte es reichen den Leuten einen Hinweis zu geben, dass sie noch etwas nachinstallieren müssen (und eine Handreichung wie, vorzugsweise in der CRef). Achte lieber auf eine gute Fehlerbehandlung wenn notwendige Komponenten fehlen.
ZitatIst so ein Modul überhaupt im Standard erwünscht, das Standalone nicht funktionieren kann (und die Installation auch nicht aus FHEM anstoßen kann, da mit root und nur Linux)?
Einerseits moechte ich den Leuten das Leben einfach machen, andererseits haben viele FHEM-Module weitreichende Abhaengigkeiten von anderen Dateien bzw. installierten Programmen, und wir koennen / wollen / duerfen nicht alles bei uns duplizieren.
Deshalb der Beschluss, alles was eigentlich anderswo beheimatet wird, wird nicht direkt mit FHEM ausgeliefert. Konkretes Beispiel: die diversen CPAN Module, wie Device::SerialPort. Auf meinem TODO liegt sowas wie jquery, CodeMirror, etc. rauszuwerfen, bzw. bei der FHEM-Installation diese Pakete automatisch herunterzuladen.
Dein Fall ist speziell: ich kann nachvollziehen, dass bestimmte Bibliotheken zu uebersetzen manche Anwender ueberfordert.
Wenn eine Bauanleitung andererseits zuzumuten ist, dann ziehe ich das vor.
Ich habe jetzt ein thirdparty Verzeichnis angelegt, mit folgendem README da drin:
ZitatThis is the place for thirdparty files.
Requirements:
- the file itself cannot be easily downloaded from the "native" site, or
building it from source (by supplying a description) is not reasonable.
- the licence is compatible with GPLv2
- the file (or files) is residing in a subdirectory describing its
name (e.g. libXYZ)
- the directory contains a README, with following content:
- the exact licence
- the current maintainer
- which module is in need of this file
- why is it not feasible to just download the file or build it
Alternativ gibt es ja noch github.com/fhem wo Du Dein Repository gerne hinziehen kannst. Ich müsste Dich nur als Mitglied eintragen.
Es gab mal mit dem Modul Installer Bemühungen eine einfache Installation diverser 3rth Part Module zu ermöglichen welche auf GitHub liegen.
Zitat von: Christoph Morrison am 08 Februar 2021, 13:41:37
Für meinen Geschmack sollte es reichen den Leuten einen Hinweis zu geben, dass sie noch etwas nachinstallieren müssen (und eine Handreichung wie, vorzugsweise in der CRef). Achte lieber auf eine gute Fehlerbehandlung wenn notwendige Komponenten fehlen.
Deswegen reift da gerade mithilfe der Foren Teilnehmer ein Install Script, das alle Abhängigkeiten auflöst, Config Files generiert und installiert und durch den komplexen Registrierungsprozess führt.
Nur eben die beiden Libraries zu übersetzen, dürfte sich allein schon deswegen nicht integrieren lassen, weil ich das auf meinem Raspi4 mit 4GB Speicher zwar geschafft habe, es aber durchaus Hinweise gibt, das du mit weniger Speicher evtl. schon verloren hast. D.h. Cross Compilation wo anders. Und da würde ich aktuell dran auch scheitern (da ich gradle zu wenig kenne).
Dann kommen die jetzt wie unten von Rudi beschrieben ins Thirdparty und werden vom Installer per wget geholt.
Gruß und Danke,
Jörg
Ok, habe meines Sachen jetzt hinzugefügt.
Lasst mich wissen ob das so ok ist.
Jörg
Fuer mich perfekt.