Bereitstellung von Binaries zum Download

Begonnen von Adimarantis, 04 Februar 2021, 17:25:01

Vorheriges Thema - Nächstes Thema

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Adimarantis

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

CoolTux

Ich denke mit einem entsprechenden Verweis auf die Githubseite sollte das kein Problem sein.
Schauen wir mal was die anderen sagen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

rudolfkoenig

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.

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

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.

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

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.

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!