Bereitstellung von Binaries zum Download

[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

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

[Adimarantis]

Alles GPL

Jörg

[CoolTux]

Ich denke mit einem entsprechenden Verweis auf die Githubseite sollte das kein Problem sein.
Schauen wir mal was die anderen sagen.

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

[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

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

[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

[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]

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.

[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

Code: [Auswählen]

wget https://svn.fhem.de/fhem/trunk/fhem/thirdparty/Adimarantis/<dateiname> gehen.

Gruß,
Jörg

[betateilchen]

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.

[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]

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.