Da update nicht ohne mein Zutun neue Verzeichnisse verteilt, wurde ich gefragt, ob es OK waere, die in diesem Thema (https://forum.fhem.de/index.php/topic,59251.0.html) erwaehnte winconnect.exe ins SVN einzuchecken, und per update zu verteilen. Ich habe erstmal mein Bedenken geaeussert, mit dem Argument:
Zitat- FHEM ist unter GPL, d.h. der Benutzer bekommt die Quellen, und ich finde sie in deinem Fall nicht.
- ich habe bisher vermieden Binaerdateien zu verteilen, mW waere das in deinem Fall eine Premiere.
Ich will aber niemanden behindern, und vielleicht fallen mir hier nur die falschen Argumente ein, deswegen die Frage hier nochmal im Forum, wo wir die Grenze ziehen sollten. Achtung: es geht hier um prinzipielle Fragen, eine Abstimmung zu starten ist zwecklos.
Ich finde man kann die exe auch separat über ein Git anbieten und in der Commandref darauf hinweisen das das Modul die Installation benötigt um zu funktionieren.
Oder einfach nach der Definition einer Instanz darauf hinweisen wenn kein Connect zu Stande kommt.
Nur wegen einer einzigen binären Datei das Konzept zu brechen empfinde ich als abwegig.
Grüße
Sind die Firmware Dateien für diverse Microcontroller nicht auch binärdateien?
Der Quellcode ist bei diesen Dateien auch nur über Umwege zu finden.
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
Zitat von: Sidey am 22 Juli 2017, 20:29:07
Sind die Firmware Dateien für diverse Microcontroller nicht auch binärdateien?
Der Quellcode ist bei diesen Dateien auch nur über Umwege zu finden.
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
Stimme ich Dir zu. Aber ich finde auch das eine ausführbare Datei (exe) noch mal eine Nummer größer ist.
Hi,
also eine winconnect.exe finde ich in dem Thread nicht. Wahrscheinlich ist WinControl.exe gemeint, oder?
Soweit ich das verstehe, ist das Modul dazu da einen Windows-PC von FHEM aus zu steuern. Dabei läuft FHEM nicht auf demselben PC. Die WinControl.exe muss dafür auf dem PC laufen, also nicht auf dem FHEM-Server. D.h. es bringt erstmal nichts, das Ding mit FHEM auszuliefern, da man sie sowieso auf den Windows-Rechner kopieren muss und dort dafür sorgen muss, dass sie auch läuft. Oder sehe ich das falsch?
Da ist es im Zweifelsfall sogar einfacher, sich die exe-Datei z.B. von GitHub zu holen, wenn in der Doku (oder sogar in einer Fehlermeldung des Moduls) der Link erwähnt ist.
Ansonsten wäre mir auch nicht so ganz klar, unter welcher Lizenz die exe-Datei steht und ob sie dem Fragenden "gehört". Normalerweise bekommt man bei komplett freien Sachen immer den Quellcode mit. Ansonsten wäre ich da auch skeptisch.
Gruß,
Thorsten
Zitat von: rudolfkoenig am 22 Juli 2017, 20:00:27Ich will aber niemanden behindern, und vielleicht fallen mir hier nur die falschen Argumente ein, deswegen die Frage hier nochmal im Forum, wo wir die Grenze ziehen sollten.
Ich sehe erstmal grundsätzlich kein Problem darin auch Binaries zu verteilen, sofern sie sinnvolle Funktionen erfüllen.
Allerdings sehe ich gleich zwei Probleme darin das mit Binaries zu tun, für die es keinen Quellcode gibt:
Das eine ist ideologisch bezogen auf die GPL, da ich der Meinung bin dass jeder User die Chance haben sollte auch den FHEM Code anzupassen.
Das zweite ist die Verantwortung gegenüber den Usern nicht irgendwelche ausführbaren Dateien unter die Leute zu bringen von denen du nicht nur nicht weisst was sie tun, sondern das auch nicht einfach rausfinden kannst.
tl;dr: Wer irgendwelchen Kram im offiziellen Repository haben will soll seinen Quellcode dazu veröffentlichen. Zumindest per Link auf Github o.ä.
Was spräche dagegen, diese exe-Datei in ./contrib bereitzustellen, aber nicht auf dem offiziellen update-Weg zu verteilen?
Sie würde also im FHEM SVN liegen aber nicht bei den Usern? Ist doch doof, dann kann der Maintainer ja gleich sein Git nehmen um das zu verteilen. Was meinst wie viele dann kommen und fragen wo finde ich die Datei noch mal und wie muss ich sie runter laden?
Und sie werden es nicht im entsprechenden Thread fragen sondern unter Anfänger wo die Helfenden selbst erstmal schauen müssen.
Hallo,
Ich bin der Entwickler dieser exe. Grundsätzlich ist es so dass der Benutzer selber die Anwendung auf seinem windows pc einrichten muss! Da Anwendung soll nur deswegen auf dem FHEM Server liegen damit der Benutzer bei einem Update sein Endgerät automatisch auch auf die aktuelle Version Patchen kann. Auch diese Updatefunktion muss der Benutzer erst aktivieren. Im Endeffekt ist es wie bei deinem AMAD Modul. Beides sollte halt zusammen passen.
Gruß
Michael
Gesendet von iPhone mit Tapatalk
Zitat von: michael.winkler am 22 Juli 2017, 21:25:38
Hallo,
Ich bin der Entwickler dieser exe. Grundsätzlich ist es so dass der Benutzer selber die Anwendung auf seinem windows pc einrichten muss! Da Anwendung soll nur deswegen auf dem FHEM Server liegen damit der Benutzer bei einem Update sein Endgerät automatisch auch auf die aktuelle Version Patchen kann. Auch diese Updatefunktion muss der Benutzer erst aktivieren. Im Endeffekt ist es wie bei deinem AMAD Modul. Beides sollte halt zusammen passen.
Gruß
Michael
Gesendet von iPhone mit Tapatalk
Wärst Du denn bereit den Quellcode mit zu liefern? Dann könnte man in contrib ein eigenes Verzeichnis winkler machen und ausliefern. Ohne ausliefern hätte es ja keinen Nutzen.
Zitat von: CoolTux am 22 Juli 2017, 21:13:36
Was meinst wie viele dann kommen und fragen wo finde ich die Datei noch mal und wie muss ich sie runter laden?
Das ist doch alles auf svn.fhem.de beschrieben und sogar trac ist dorthin verlinkt.
Zitat
To browse the repository, you can use our Trac.
Damit muss ein Entwickler eben NICHT mehr sein eigenes git einrichten, sondern kann die Infrastruktur von FHEM nutzen.
Darüber habe ich mir noch keine Gedanken gemacht. Ist halt fraglich ob es dem Anwender hilft wenn er den Sourcecode hat. Vom Ablageort muss es halt so sein das die Anwendung in einem Bereich liegt der über einen http Aufruf zum Download bereit steht. Wäre das im Contrib Verzeichnis gegeben?
Gesendet von iPhone mit Tapatalk
Nein. Das wäre aber im ganzen ./FHEM Ordner nicht gegeben, es sei denn Du baust es in Deinem Modul so ein.
Anmerkung: Udo hat natürlich Recht wenn Du das SVN meinst, solltest Du es aus FHEM heraus meinen dann passt mein obriges.
Zitat von: michael.winkler am 22 Juli 2017, 21:34:18
Vom Ablageort muss es halt so sein das die Anwendung in einem Bereich liegt der über einen http Aufruf zum Download bereit steht. Wäre das im Contrib Verzeichnis gegeben?
JA.
Aus trac kannst Du jede Datei per http abrufen, und das funktioniert sogar von Windows aus, ohne dass der Anwender ein spezielles svn- oder git-Tool bedienen können muss.
Was haltet Ihr davon. Das exe File in Contrib, nicht mit verteilen beim Update Prozess, dafür ein Link in die Commandref welcher auf die exe im svn verweist.
Dennoch finde ich sollte der Sourceforge Sourcecode mit ins SVN
Zitat von: CoolTux am 22 Juli 2017, 21:59:07
sollte der Sourceforge mit ins SVN
du meinst wohl Source
code...
So, jetzt bin ich am PC und kann etwas ausführlicher schreiben.
Grundsätzlich ist es ja so dass FHEM nur dann mit einem Endgerät kommunizieren kann wenn irgendeine Möglichkeit besteht dies über Netzwerk oder Ähnliche zu erreichen. In der Regel sind diese Schnittstellen von Haus aus schon am Endgerät oder über ein Gateway erreichbar.
Im Fall von dem 70_WINCONNECT.pm Modul ist es letztendlich genauso. Nur muss der Anwender zusätzlich auf seinem PC ein Stück Software installieren. Für mich als Entwickler des Modules und der Anwendung wäre es natürlich Wünschenswert wenn beides immer auf demselben Stand wäre.
Aus diesem Grund habe ich bei Rudi gefragt ob es möglich sein meine Anwendung für genau diesen Update Prozess hier ,,opt/fhem/www/winconnect" abzulegen.
Sollte das wirklich nur mit offenlegen meines Sourcecodes geht, werde ich diesen Schritt wahrscheinlich nicht gehen. Gerade bei so einer Anwendung besteht die Gefahr, dass jemand andere auf Basis meines Sourcecode weiterentwickelt und hier wirklich Dinge einbaut die dem Anwender schaden. Wer kann später schon wirklich unterscheiden ob die Anwendung von mir kommt oder von jemanden anderes.
Sollte mein Anfrage wirklich abgelehnt werden, muss ich mir halt andere Wege überlegen wie ich dem Anwender, so angenehm wie möglich, diesen Updateprozess gestalten kann.
Wenn ich mich nicht täusche habe ich in der Datei ,,/fhem/contrib/WebViewControl/packages/WebViewControl-0.4a.zip" auch eine Anwendung gefunden wo der Sourcecode fehlt.
Ich bin keinem Böse wenn Ihr meinen Antrag/Anfrage ablehnt.
Gruß
Michael
Aus meiner Sicht spricht nichts gegen die Veröffentlichung von Binaries im svn, wenn der aktuelle Sourcecode dazu im gleichen Repository veröffentlicht wird. Bei den Microcontroller Binaries störte es mich auch schon, dass ich erst auf die Suche gehen mußte und wahrscheinlich nur ähnlichen Code gefunden habe. Die Binaries selbst finde ich für Anfänger hilfreich.
Wenn der Source nicht verfügbar gemacht wird, dann haben Binaries mMn im FHEM Repository nichts zu suchen, es ist ein Open Source Projekt.
ZitatIst halt fraglich ob es dem Anwender hilft wenn er den Sourcecode hat.
Dem reinen Anwender sicherlich nicht, aber es gibt zB. auch Entwickler, die FHEM nutzen, weil sie nicht die Katze im kaufen wollen.
ZitatGerade bei so einer Anwendung besteht die Gefahr, dass jemand andere auf Basis meines Sourcecode weiterentwickelt und hier wirklich Dinge einbaut die dem Anwender schaden.
Diese Gefahr besteht bei Binaries immer. Auch Dir kann man nur vor den Kopf gucken und nicht hinein. Das ist jetzt nicht persönlich gemeint und ich möchte Dir auch nichts unterstellen.
EDIT: Sollte der Sourcecode nicht veröffentlicht werden, dann würde ich sogar in Frage stellen wollen, ob das entsprechende FHEM Modul überhaupt im FHEM geführt werden sollte. Bei diesem Gedanken ist mir schon klar, dass wir mit FHEM viele Geräte steuern, dessen Sourcecode wir nicht kennen. Wenn es aber die Möglichkeit gibt, dann sollten wir nicht darauf verzichten, zumindendest nicht weil einige/viele Anwender damit nichts anfangen können oder jemand alternative Binaries veröffentlichen kann.
Hallo,
bei FHEM geht es um Open Source. Das ist auch der Vereinszweck des FHEM e.V. als Betreiber der Infrastruktur. Eine weitere Befassung mit der Frage, ob ein Binary über das Update verteilt wird, ergibt nur Sinn, wenn vorab geklärt ist, dass der Quellkode verfügbar gemacht wird.
Viele Grüße
Boris
Hi,
Zitat von: michael.winkler am 23 Juli 2017, 00:07:01
Sollte das wirklich nur mit offenlegen meines Sourcecodes geht, werde ich diesen Schritt wahrscheinlich nicht gehen. Gerade bei so einer Anwendung besteht die Gefahr, dass jemand andere auf Basis meines Sourcecode weiterentwickelt und hier wirklich Dinge einbaut die dem Anwender schaden. Wer kann später schon wirklich unterscheiden ob die Anwendung von mir kommt oder von jemanden anderes.
Das ist meiner Meinung nach ein etwas seltsames Argument. Damit könnte man jegliche Open-Source-Entwicklung "erschlagen". Normalerweise wird es anders herum gesehen: Open Source macht die Software sicherer, weil man sich zumindest theoretisch davon überzeugen kann, dass da nichts "gefährliches" schlummert.
ZitatWenn ich mich nicht täusche habe ich in der Datei ,,/fhem/contrib/WebViewControl/packages/WebViewControl-0.4a.zip" auch eine Anwendung gefunden wo der Sourcecode fehlt.
Das kann schon sein, aber...
- Das wurde soweit ich weiß auch schon kritisiert.
- Ich glaube, da geht es tatsächlich um Lizenzprobleme.
- Es ist im contrib-Ordner
- Nur weil es anderswo falsch läuft, kann man es bei sich trotzdem "richtig" machen.
Hmmm... Das klingt jetzt alles so, als ob ich absolut dagegen wäre, es an dieser Stelle dem Benutzer einfacher zu machen. Das wollte ich damit nicht sagen. Ich finde es aber inakzeptabel, etwas mit FHEM zu verteilen, zu dem man keinen Quellcode hat, insbesondere wenn das in Frage stehende Stück Software für FHEM entwickelt wurde, der Quellcode zur Verfügung steht und es keine rechtlichen Probleme gibt.
Gruß,
Thorsten
Zitat von: michael.winkler am 23 Juli 2017, 00:07:01
Wenn ich mich nicht täusche habe ich in der Datei ,,/fhem/contrib/WebViewControl/packages/WebViewControl-0.4a.zip" auch eine Anwendung gefunden wo der Sourcecode fehlt.
Ich bin der Ansicht, dass wir diese Datei aus dem Repo entfernen sollten.
Zitat von: Dr. Boris Neubert am 23 Juli 2017, 10:15:46
Ich bin der Ansicht, dass wir diese Datei aus dem Repo entfernen sollten.
Da bin ich der erste der dabei ist. Zumal das ganze seit Jahren mehr schlecht als Recht in Betrieb zu nehmen ist.
Zurück zum eigentlichen.
Unter ./www hat das ganze schon mal gar nichts zu suchen.
Ich bleibe bei meinem Vorschlag und möchte diesen gerne noch bestärken
Nur mit Sourcecode bekommt Micha einen eigenen Ordner unterhalb von Contrib. Dieser Ordner wird NICHT für Update bereit gestellt. Micha baut in seiner Commandref oder seinem Modul ein Link ein unter dem man die Datei vom SVN runterladen kann.
Grüße
Zitat von: CoolTux am 23 Juli 2017, 10:23:33
Zumal das ganze seit Jahren mehr schlecht als Recht in Betrieb zu nehmen ist.
@CoolTux: WebViewControl liegt sicher nicht ohne Grund in ./contrib ;)
(Wobei der Browser, der im gerade diskutierten zip enthalten ist, bei mir einen tollen Job in Kombination mit InfoPanel macht. Unabhängig davon, ob man das zu wvc gehörende perl Modul einsetzt oder nicht)
Zitat von: michael.winkler am 23 Juli 2017, 00:07:01
Wenn ich mich nicht täusche habe ich in der Datei ,,/fhem/contrib/WebViewControl/packages/WebViewControl-0.4a.zip" auch eine Anwendung gefunden wo der Sourcecode fehlt.
Der Sourcecode ist afaik hier öffentlich: https://github.com/kc-GitHub/WebViewControl
Die ganze Diskussion führ doch jetzt an allem vorbei!
Zitat von: Dr. Boris Neubert am 23 Juli 2017, 10:04:55
Hallo,
bei FHEM geht es um Open Source. Das ist auch der Vereinszweck des FHEM e.V. als Betreiber der Infrastruktur. Eine weitere Befassung mit der Frage, ob ein Binary über das Update verteilt wird, ergibt nur Sinn, wenn vorab geklärt ist, dass der Quellkode verfügbar gemacht wird.
Viele Grüße
Boris
Diese Aussage trifft es doch. Über genau diese Punkt sollte diskutiert werden. Legt doch einfach die Rahmenbedingen für eine Binaerdatei fest und gut ist. Dann könnt ihr bei der nächsten anfrage ganz klar auf diese verweisen, und alle wissen bescheid.
Zitat von: dev0 am 23 Juli 2017, 09:35:52
EDIT: Sollte der Sourcecode nicht veröffentlicht werden, dann würde ich sogar in Frage stellen wollen, ob das entsprechende FHEM Modul überhaupt im FHEM geführt werden sollte.
Wenn ich dann solche Aussagen lese kann man nur mit dem Kopf schütteln.
Zitat von: Thorsten Pferdekaemper am 23 Juli 2017, 10:08:55
Hmmm... Das klingt jetzt alles so, als ob ich absolut dagegen wäre, es an dieser Stelle dem Benutzer einfacher zu machen. Das wollte ich damit nicht sagen. Ich finde es aber inakzeptabel, etwas mit FHEM zu verteilen, zu dem man keinen Quellcode hat, insbesondere wenn das in Frage stehende Stück Software für FHEM entwickelt wurde, der Quellcode zur Verfügung steht und es keine rechtlichen Probleme gibt.
Das kann ich so nicht ganz bestätigen. Grundsätzlich ist die Anwendung ein Abfallprodukt aus einer anderen Entwicklung. Dort gibt es die Anwendung als Windows-Dienst und wird über eine andere Plattform abgefragt. Da ich privat einen FHEM Server verwende, entwickle ich dementsprechend für beide Plattformen.
Ich für mich habe aus Eurer Diskussion herausgehört dass der Großteil von Euch es nicht möchte und genau darauf stelle ich mich jetzt ein.
Gruß
Michael
Hallo,
wie Rudi bereits schrieb: eine Mehrheitsentscheidung wird es in dieser Sache nicht geben. Wir hören die unterschiedlichen Positionen an und entscheiden dann.
Viele Grüße
Boris
Zitat von: michael.winkler am 23 Juli 2017, 12:25:59Wenn ich dann solche Aussagen lese kann man nur mit dem Kopf schütteln.
Warum? Würdest du das auch noch denken, wenn z.B. jemand ein Modul im SVN haben möchte, das nur mit seiner eigenen, kostenpflichtigen iOS/Android/Win App funktioniert?
ZitatIch für mich habe aus Eurer Diskussion herausgehört dass der Großteil von Euch es nicht möchte und genau darauf stelle ich mich jetzt ein.
Ich habe herausgehört dass alles ok ist, solange der Quellcode zur Verfügung steht.
Und das gilt selbstverständlich auch nur für den FHEM-kompatiblen Teil.
Zurück zum Beispiel WebViewControl:
Hätte ich den Quellcode an dem Punkt gehabt an dem ich ihn gebraucht hätte weil es mit meinen Geräten inkompatibel war, würde ich es heute wahrscheinlich einsetzen und hätte die Entwicklung unterstützt. So ist es mehr oder weniger eingeschlafen.
Und das ist ein weiterer wichtiger Punkt: Zukunftssicherheit. Wenn du mal keine Lust mehr hast dich um das Modul zu kümmern, sollte es zumindest möglich sein dass jemand anders übernimmt.
Zitat von: Markus M. am 23 Juli 2017, 14:48:39
Zurück zum Beispiel WebViewControl:
Hätte ich den Quellcode an dem Punkt gehabt an dem ich ihn gebraucht hätte weil es mit meinen Geräten inkompatibel war, würde ich es heute wahrscheinlich einsetzen und hätte die Entwicklung unterstützt. So ist es mehr oder weniger eingeschlafen.
Und das ist ein weiterer wichtiger Punkt: Zukunftssicherheit. Wenn du mal keine Lust mehr hast dich um das Modul zu kümmern, sollte es zumindest möglich sein dass jemand anders übernimmt.
Hihi, wenn ich da mal ein kleines Gegenargument bringen darf. Hätte dieses vermaledeite Webviewcontrol damals bei mir vernünftig funktioniert, gebe es heute AMAD nicht.
Also ich bin froh darüber das es heute AMAD gibt. ;D
Zitat von: Markus M. am 23 Juli 2017, 14:48:39
Warum? Würdest du das auch noch denken, wenn z.B. jemand ein Modul im SVN haben möchte, das nur mit seiner eigenen, kostenpflichtigen iOS/Android/Win App funktioniert?
Es gibt sehr wohl Module, welche auf kostenpflichtige Teile angewiesen sind. Selbst AMAD benötigt einen Softwareteil der Geld kostet. Und auch diese Software hat sicherlich seinen Sourcecode nicht veröffentlicht. Soll das Modul dann auch ausgeschlossen werden? Ich denke eher nicht, und genau aus diesem Grund kann ich über die Aussage "Sollte der Sourcecode nicht veröffentlicht werden, dann würde ich sogar in Frage stellen wollen, ob das entsprechende FHEM Modul überhaupt im FHEM geführt werden sollte" nur den Kopf schütteln.
Zitat von: CoolTux am 23 Juli 2017, 14:56:52
Hihi, wenn ich da mal ein kleines Gegenargument bringen darf. Hätte dieses vermaledeite Webviewcontrol damals bei mir vernünftig funktioniert, gebe es heute AMAD nicht.
Also ich bin froh darüber das es heute AMAD gibt. ;D
Wenn morgen jemand ein besseres Modul schreibt und dadurch meines verdrängt wäre das für mich auch nicht schlimm. So etwas passiert immer wieder mal.
Um mal wieder zum wesentlichen zurückzukommen. Für WinnConnect macht es keinen Sinn die GUI an einen Ort zu legen wo ich sie im laufenden Betrieb nicht über einen HTTP://fehserver:port/.... abholen kann. Deswegen braucht wir auch darüber nicht zu diskutieren. Im aktuellen ./www Verzeichnis sind heute schon einige Skript / Code usw. drin, ob da jetzt noch eine EXE dazukommt wäre für mich nicht schlimm. Generell wäre diese Diskussion aber erst dann zu führen, wenn generell geklärt wäre ob auf dem FHEM SVN eine Anwendung liegt wo der Sourcecode nicht zur Verfügung steht. Aber aus Lizenzrechtlichen Gesichtspunkt nicht dagegen sprechen würde.
Ich persönlich kann es verstehen wenn die FHEM Entwickler diese nicht wollen, und bin hier auch keinem Böse.
Zitat von: michael.winkler am 23 Juli 2017, 16:52:21
Um mal wieder zum wesentlichen zurückzukommen. Für WinnConnect macht es keinen Sinn die GUI an einen Ort zu legen wo ich sie im laufenden Betrieb nicht über einen HTTP://fehserver:port/.... abholen kann. Deswegen braucht wir auch darüber nicht zu diskutieren. Im aktuellen ./www Verzeichnis sind heute schon einige Skript / Code usw. drin, ob da jetzt noch eine EXE dazukommt wäre für mich nicht schlimm.
Die Datei muß nicht unter www liegen. Am Anfang konnte man die xml AMADautomagicFlowsets auch über die Detailseite seines definierten AMAD Devices runterladen. Dabei spielte es keine Rolle das das Flowset unter ./FHEM/lib/ lag.
Du musst nur eine entsprechende Funktion in Deinem Modul einbauen.
Grüße
Zurück zum Thema:
Open Source bedeutet, dass der Quellcode öffentlich zugänglich ist.
Open Source bedeutet nicht, dass keine fertig compilierten binarys bereitgestellt werden dürfen.
Als Beispiel möchte ich Mal eines der erfolgreichsten Open Source Betriebssysteme nennen: Linux
Dort installieren wir regelmäßig binarys über rpm Pakete oder ähnliches.
Den Sourcecode ist öffentlich zugänglich. Ob der immer im gleichen Repository steckt oder sonst wie verteilt wird spielt doch kaum eine Rolle.
Ich bin mir sicher, dass der Sourcecode nicht in den Live CDs oder ähnlichen integriert ist.
Meiner Meinung nach, interessiert den Anwender den Sourcecode auch nicht. Den interessiert es eher, dass es einfach ist. Compilierten will der nicht.
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
Folgendes habe ich Michael gerade geantwortet:
ZitatHallo Michael,
> ist hier schon eine Entscheidung gefallen?
ja. FHEM ist GPL, fuer alles was eingecheckt wird, muessen die Quellen
verfuegbar sein.
Binaries werden nicht per update verteilt, sie koennen aber gerne nach contrib
eingecheckt werden, um die Versionierung von FHEM zu verwenden.
Gruss,
Rudi
ZitatEs gibt sehr wohl Module, welche auf kostenpflichtige Teile angewiesen sind. Selbst AMAD benötigt einen Softwareteil der Geld kostet.
Dieses Argument zaehlt nicht: fast alles, mit dem FHEM kommuniziert, ist closed source und kostenpflichtig (Funkschalter, Heizungssteuerung, Fernseher, Musikanlage, Alexa/Siri, Spotify, etc). Aber alles was in svn.fhem.de eingecheckt ist, muss Open-Source sein, da ganz vorne steht: FHEM steht unter GPL.
Zitat von: Rudi
Binaries werden nicht per update verteilt, sie koennen aber gerne nach contrib
eingecheckt werden, um die Versionierung von FHEM zu verwenden.
*gefällt mir*
Zitat von: betateilchen am 26 Juli 2017, 13:41:58
*gefällt mir*
Sorry, verstehe ich nicht.
Bedeute dies nun, dass alles was nicht im Ascii Format vorliegt, nach contrib muss?
Und für contrib gibt es keinen Update Mechanismus?
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
Nein, mit Binaerdaten habe ich "ausfuehrbare Binaerdateien" gemeint. Also etwas, was nur auf einem bestimmten Plattform laeuft, wie z.Bsp. eine .exe Datei fuer Windows, ein Linux-Binary oder eine Firmware-Datei.
Und um auch noch diesen Teil der Frage zu beantworten:
Zitat von: Sidey am 26 Juli 2017, 17:58:34
Und für contrib gibt es keinen Update Mechanismus?
- ./contrib wird einmalig bei der Erstinstallation von FHEM im Installationspaket mitgeliefert
- ./contrib ist nicht im regulären update-Mechanismus (98_update.pm) enthalten
Aber das ist doch eigentlich nix Neues.
Zitat von: betateilchen am 26 Juli 2017, 19:38:43
- ./contrib wird einmalig bei der Erstinstallation von FHEM im Installationspaket mitgeliefert
- ./contrib ist nicht im regulären update-Mechanismus (98_update.pm) enthalten
Aber das ist doch eigentlich nix Neues.
Dann hätte man sich die ganze Diskussion sparen können!
Du kannst doch Dein git ins update aufnehmen, evtl sogar per automatik im modul (das würde ich den user ab-nicken lassen, oder per attrib oder so). Kennst Du das ? (Zusätzlich quellen ins update des users)
vg
joerg
Zitat von: herrmannj am 26 Juli 2017, 22:23:19
Du kannst doch Dein git ins update aufnehmen, evtl sogar per automatik im modul (das würde ich den user ab-nicken lassen, oder per attrib oder so). Kennst Du das ? (Zusätzlich quellen ins update des users)
vg
joerg
nein kenne ich nicht
https://wiki.fhem.de/wiki/Update#Repository-Verwaltung
Zitat von: herrmannj am 26 Juli 2017, 22:23:19
Du kannst doch Dein git ins update aufnehmen,
Diese verteilten repositories für das update sind zwar theoretisch eine gut gemeinte Idee, aber in der Praxis ein Krampf für alle, die ihr FHEM nicht per 98_update.pm aktualisieren, sondern über andere Updatemechnismen.
Hast du einen konstruktiven Vorschlag?
Ich wuesste auch gerne, wieviele direkt per "svn update" aktualisieren.
kann ja jeder selber entscheiden. Wer fhem eigenen update Befehl verwendetet (so wie es vorgesehen ist) hat kein Problem. Mir ist klar das Du per svn updatest, das ist aber ja so auch nicht gedacht und die Cmdref schreibt genau das https://fhem.de/commandref_DE.html#update
Zitat von: rudolfkoenig am 27 Juli 2017, 09:38:50
Hast du einen konstruktiven Vorschlag?
Nur so vor mich hingedacht:
- ähnlich wie bei Linux Distributionen zusätzlich zum Unterverzeichnis ./contrib einen Unterordner ./non-free anlegen, in den solche Binärdateien abgelegt werden können
- diesen Ordner optional in den regulären update-Mechanismus einbinden (attr global includeNonFree 1)
- für jeden Unterordner in ./non-free muss zweifelsfrei angegeben und nachgewiesen werden, welche Lizenzbedingungen dafür gelten. Die Verantwortung für diese Aufgabe liegt bei dem, der dort etwas einchecken möchte
- damit ließe sich auch dokumentieren, dass Dateien in/unterhalb dieses Ordners nicht zwingend unter der GPL von FHEM stehen
Zitat von: herrmannj am 27 Juli 2017, 09:42:05
Mir ist klar das Du per svn updatest, das ist aber ja so auch nicht gedacht
Nachdem selbst Rudi das Vorgehen dazu schon hier im Forum beschrieben hat, ist das für mich aber längst keine "persönliche Ausnahme" mehr.
Zitat von: rudolfkoenig am 27 Juli 2017, 09:38:50
Ich wuesste auch gerne, wieviele direkt per "svn update" aktualisieren.
Das läßt sich nicht feststellen. Du kannst zwar SVN Abrufe serverseitig zählen, weißt aber noch lange nicht
- ob es sich um eine laufende FHEM Installation handelt
- ob es sich um ein update per cmdalias oder per cronjob oder manuell über einen SVN client handelt
Bei mir ist es so, dass ich per svn aktualisiere, diese Aktualisierung landet in einem git repository und aus diesem privaten git repo aktualisieren sich meine FHEM Installationen (damit nicht jede Installation selbst den FHEM Server kontaktieren muss)
mal im Ernst, welchen Grund gibt es denn das svn update in die offiziellen Überlegungen einzubeziehen ?
fhem hat einen update Befehl und damit ist das für mich der einzige supportete Weg. Aus gutem Grund wie die aktuelle Diskussion doch zeigt. Da kann man repositories einbinden. Im übrigen mag es ja in der Zukunft auch mal notwendig werden ein Migrationsscript (warum auch immer) zu triggern. Vielleicht verstehe ich den Punkt auch nicht. Wenn fhem update Unzulänglichkeiten hat die den Normaluser(!) betreffen (und in die svn Lösung treiben?) dann muss man die anpacken.
Aktuell ist das für mich aber Sonnenklar: update -> fhem update. Wer was anderes will darf natürlich muss aber dann eben auch eigene Lösungen für Sonderfälle schaffen.
Zitat von: herrmannj am 27 Juli 2017, 10:03:30
Aktuell ist das für mich aber Sonnenklar: update -> fhem update.
Nur weil das bisher immer so war? Dann hätten wir auch die Statistik nicht neu machen brauchen.
Man kann und darf doch immer darüber nachdenken, ob eine seit Jahren praktizierte Vorgehensweise grundsätzlich noch zeitgemäß ist.
FHEM hat sich in den vergangenen Jahren geändert. Warum sollte man nicht über die zugehörigen Prozesse nachdenken und sie in Frage stellen?
In FHEM werden schließlich regelmäßig und ohne vorherige Diskussion grundlegende Dinge geändert "die immer so waren" und damit oft massive Probleme geschaffen. Deshalb finde ich die Diskussion über die Vorgehensweise hier durchaus sinnvoll und zulässig.
Wenn ich etwas zu entscheiden hätte, wäre der update-Befehl in seiner jetzigen Form das Erste, was ich abschaffen würde. Damit würden viele Dinge einfacher und eine Menge Problemthreads im Forum ließen sich vermeiden.
Letztendlich ist doch der derzeitige Update-Befehl in FHEM nix anderes als ein mehr oder wenig guter Wrapper um ein "svn update" das auf dem FHEM Server ausgeführt und dann nachbearbeitet wird.
Ok verstanden. Aber in der Diskussion werden jetzt zwei Dinge vermischt. Wie kommen die Dateien zum User und was ist drin. Für den normal User ist es doch egal ob er sich die Probleme (ich übernehme das mal ungefiltert) via fhem Update oder Svn Update nach Hause holt. Im ersten Fall aber bequem (siehe dieser Thread). Bleiben wir beim wie: Fhem Update. Inklusive fremd Quellen. Lass uns doch mal darüber nachdenken da ein rollback einzubauen.
Ich sehe gerade beim Einbinden von "Fremdquellen" den Vorteil des FHEM update-Befehls. So kann ich z.B. die Beta-Version von Signalduino nutzen, ohne umständlich die Module von GitHub in FHEM einzubinden. Natürlich könnte man jetzt auch andere Quellen in einem eigenen Skript unterbringen, das ist aber alles andere als anwenderfreundlich.
Ich füge unter Linux auch lieber eine Paketquelle zur apt-Liste hinzu, als die Software manuell herunterzuladen und zu installieren. Das vereinfacht das Prüfen auf Updates ungemein. Das sehe ich immer wieder unter Windows, wo ich für jedes Programm separat prüfen muß, ob es noch aktuell ist.
Zitatähnlich wie bei Linux Distributionen zusätzlich zum Unterverzeichnis ./contrib einen Unterordner ./non-free anlegen, in den solche Binärdateien abgelegt werden können
Ich meine hier werden drei Sachen vermischt: 1.Einchecken von nicht GPL lizensierten Dateien ins FHEM-SVN, 2. Verteilen von Binaerdaten per FHEM-update und 3. eine Moeglichkeit, mehrere Fremd-Repositories parallel mit dem "native-Verfahren" (wie svn update) aktualisieren zu koennen.
Fuer 1. und 2. sehe ich nicht die Notwendigkeit. Wir koennten eine Moeglichkeit schaffen, Binaerdateien per Befehl aus contrib oder sonstwo noch einfacher herunterzuladen, wenn das notwendig ist, CULflash macht das ja seit laengerem auch. Meine urspruengliche Frage betraf eigentlich Punkt 3, dafuer habe ich keine Idee.
Nicht ganz. Die Frage ist doch welches Problem wollen wir eigentlich lösen? SVN ist ja keine Ursache sondern ein Symptom, ich versteh aber nicht für was.
Die korrekte Antwort auf Frage 3 lautet: "fhem update Befehl". Danach findest Du auf Deiner Platte die Verzeichnisse und Dateien des SVN inkl der Fremdquellen die Du eingebunden hast. Problem gelöst.
ZitatDie korrekte Antwort auf Frage 3 lautet: "fhem update Befehl".
Damit ist das Probem nur unter dem Teppich gekehrt.
Ich kann schon verstehen, dass jemand svn update bevorzugt, damit lokale Aenderungen bleiben, und trotzdem vom update profitiert. Das ist nicht unbedingt was fuer Anfaenger, aber FHEM war urpsruenglich auch nicht fuer Anfaenger gedacht :)
Soweit ich sehe, man muss folgendes machen:
- fuer jedes Fremdrepository Parallelverzeichnisse anlegen
- alle Dateien aus den Fremdrepository per Symlink verlinken, beim update dafuer sorgen, dass nicht mehr verwendete Symlinks entfernt werden.
- svn/git/etc update fuer alle Repositories einzeln durchfuehren.
Vmtl sollte jemand dafuer ein Modul bauen :)
Zitat von: rudolfkoenig am 27 Juli 2017, 11:03:30
Damit ist das Probem nur unter dem Teppich gekehrt.
und je mehr Dreck man unter einen Teppich kehrt, umso mehr entwickelt sich der Teppich zu einer Stolperfalle...
Zitat
Soweit ich sehe, man muss folgendes machen:
- ...
- ...
- ...
- das Konzept "einzelne Dateien zum Update herunterladen" aufgeben und stattdessen ein (wie auch immer geschnürtes) update-Paket ausliefern, das auf der lokalen Installation ausgepackt und verarbeitet wird
Zitatdas Konzept "einzelne Dateien zum Update herunterladen" aufgeben und stattdessen ein (wie auch immer geschnürtes) update-Paket ausliefern, das auf der lokalen Installation ausgepackt und verarbeitet wird
Das ist wieder was anderes, hier optimierst Du den FHEM-update-Mechanismus. Dafuer muesste der Client seinen eigenen Zustand an dem Server schicken, wo ein Program das analysiert, und ein .zip Paket schnuert. Ist auch nett, loest aber nicht "dein" svn update Problem.
Es war nur ein Eintrag für den Merkzettel für das neu zu schreibende Modul 8)
Zitat von: michael.winkler am 23 Juli 2017, 00:07:01
Im Fall von dem 70_WINCONNECT.pm Modul ... muss der Anwender zusätzlich auf seinem PC ein Stück Software installieren. Für mich als Entwickler des Modules und der Anwendung wäre es natürlich Wünschenswert wenn beides immer auf demselben Stand wäre.
...
Sollte mein Anfrage wirklich abgelehnt werden, muss ich mir halt andere Wege überlegen wie ich dem Anwender, so angenehm wie möglich, diesen Updateprozess gestalten kann.
...
Ich komme auf das konkrete Problem von Michael zurück, welches ich im übrigen für absolut valide halte.
Mit dem von mir vorgeschlagenen Weg erreichst Du genau das. Du verteilst WINCONNECT ganz normal via fhem und bittest wahlweise den user
- ein zusätzliches repo einzubinden: "update add http://dein.git/controls_winconnect.txt". Dort pflegst Du die exe und die wird bei jedem fhem update mit aktualisiert, der user hat den gleichen Komfort wie gewohnt.
- baust im modul selber einen codeblock ein der das Eintragen des repos automatisch übernimmt. Das würde ich den user aber unbedingt bestätigen lassen.
Passt das für Dich ?
vg
joerg
Die Vorgehensweise sollte man ja dann auch für die Firmware Dateien so umsetzen, denn die Variante mit contrib ist meiner Meinung nach ein Rückschritt.
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
Zitat von: herrmannj am 27 Juli 2017, 14:25:19
Passt das für Dich ?
Ich werde sicherlich damit leben können.
Für mich selber macht es keinen Sinn etwas in das Contrib Verzeichnis zu legen was dann nur bei der Grundinstallation aktuell ist.
Das war ja auch nicht die Idee, sondern dass man einen Ablageplatz hat, wo bei Bedarf diese Datei "online" heruntergeladen werden kann.
@Rudi: ich glaube, man
will uns nicht verstehen.
Noch ein Erkärungsversuch...
Jede Datei, die im SVN repository von FHEM liegt (egal in welchem Ordner) kann über eine direkte URL abgerufen werden.
Beispiel für ./contrib/98_WIFILED.pm
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/98_WIFILED.pm
Wenn also ein Entwickler (s)eine Datei im SVN ablegt und sie dort pflegt, kann die aktuelle Version dieser Datei jederzeit über eine immer gleiche URL per http(s) abgerufen werden. Völlig unabhängig vom verwendeten update-Verfahren innerhalb der FHEM Installation selbst. Ein solcher Abruf läßt sich natürlich auch innerhalb eines Moduls implementieren, das diese Datei verwenden möchte.
Insofern dürfte die Aussage
Zitat von: michael.winkler am 28 Juli 2017, 17:16:43
macht es keinen Sinn etwas in das Contrib Verzeichnis zu legen was dann nur bei der Grundinstallation aktuell ist.
hoffentlich obsolet sein. Denn ob eine Datei in ./contrib auch nach der Grundinstallation von FHEM aktuell ist/bleibt, liegt alleine im Verantwortungsbereich des Entwicklers.
Zitat@Rudi: ich glaube, man will uns nicht verstehen.
Na, oder da gibts halt wenig zu verstehen :) Wenn 98_WIFILED.pm im FHEM liegt wird es per update ausgeliefert, liegt es im Contrib dann nicht. Komisch ist schon ;)
Zitat von: herrmannj am 28 Juli 2017, 22:24:12
Wenn 98_WIFILED.pm im FHEM liegt wird es per update ausgeliefert, liegt es im Contrib dann nicht
Aber genau darum geht es schon längst gar nicht mehr.
ZitatWenn 98_WIFILED.pm im FHEM liegt wird es per update ausgeliefert, liegt es im Contrib dann nicht. Komisch ist schon
Gar nicht. Fuer contrib sind die Regeln laxer, fuer FHEM (und damit update) strenger. Ich will dem Entwickler Anreize geben, um unliebsame Aufgaben wie Doku und Support zu erledigen. Und fuer die Anwendern ist das ein Qualitaetsmerkmal.
Fuer Binaerdateien gilt diese Unterscheidung natuerlich nicht, aber ich will nicht grosse Dateien (wie Binaries haeufig sind), die man nicht braucht, ueberall verteilen. Die Grenze was gross ist und was man braucht ist nicht fuer alle gerecht zu ziehen, und ich habe sie als update-Maintainer etwas willkuerlich hier gezogen.
Ist natürlich schwer zu beurteilen was grosse Dateien sind und was kleine, ich denke da hat jeder ein eigenes Gefühl dafür. Die WinConnect mit ca. 700kb gehört da sicherlich zu den etwas grösseren.
Ich verstehe auch die ganzen Argumente warum etwas ins contrib soll.
Mein anliegen war es einfach schon vorhandene Funktionen zu nutzen und nicht etwas anderes wieder zu erfinden. Aus diesem Grund habe ich überhaupt die anfrage bei Rudi gestellt. Vielleicht war diese Einstellung von mir zu naiv.
Wenn dann als Ergebnis raus kommt dass ich die Datei in ein Verzeichnis legen soll aus welchem ich sie dann später über einen HTTP(s) Aufruf erst wieder runterladen muss ist das etwas suboptimal. Für mich und den Anwender wäre es angenehmer gewesen schon integrierte FHEM Funktionen hierfür zu nutzen.
Dann wäre aus Anwendersicht eines ganz klar gewesen: Wenn er eine FHEM update macht ist alles was er nutzt auf dem aktuellsten Stand, und er weiß auch warum.
An manchen Aussagen und Argumenten ist halt doch immer wieder zu lesen
Zitat von: rudolfkoenig am 27 Juli 2017, 11:03:30
Das ist nicht unbedingt was fuer Anfaenger, aber FHEM war urpsruenglich auch nicht fuer Anfaenger gedacht :)
Mal unabhängig von dieser Diskussion habe ich mir auch schon vor einiger Zeit überlegt, dass ich im Modul Daten wie Firmware oder Definitionen nachladen möchte. Das hat den Vorteil, dass ich Moduländerungen und Firmware oder Konfiguration unabhängig voneinander aktualisieren kann.
Auf jeden Fall etwas was aus meiner Sicht lohnenswert ist.
Bislang habe ich das nur aus einem Grund nicht umgesetzt: Komplexität.
Damit meine ich jetzt nicht, einfach einen HTTP Aufruf abzusetzen, das kriege ich schon noch hin, nein vielmehr ist es ja so, dass man den Update Mechanismus zum einen nonBlocking implementieren sollte und zum anderen den Anwender auch geeignet abholen muss. Sonst macht der ja nur das altbekannte Update und gut ist.
Das ganze kann jetzt jeder ganz individuell für sich erledigen. Mir würde ja gefallen, dass wir hier etwas einheitliches finden. Der Anwender wird es uns danken, wenn Dinge durchgehend gleich implementiert sind.
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
Zitat von: michael.winkler am 29 Juli 2017, 10:16:01
Ist natürlich schwer zu beurteilen was grosse Dateien sind und was kleine, ich denke da hat jeder ein eigenes Gefühl dafür. Die WinConnect mit ca. 700kb gehört da sicherlich zu den etwas grösseren.
Ich verstehe auch die ganzen Argumente warum etwas ins contrib soll.
Mein anliegen war es einfach schon vorhandene Funktionen zu nutzen und nicht etwas anderes wieder zu erfinden. Aus diesem Grund habe ich überhaupt die anfrage bei Rudi gestellt. Vielleicht war diese Einstellung von mir zu naiv.
Wenn dann als Ergebnis raus kommt dass ich die Datei in ein Verzeichnis legen soll aus welchem ich sie dann später über einen HTTP(s) Aufruf erst wieder runterladen muss ist das etwas suboptimal. Für mich und den Anwender wäre es angenehmer gewesen schon integrierte FHEM Funktionen hierfür zu nutzen.
Dann wäre aus Anwendersicht eines ganz klar gewesen: Wenn er eine FHEM update macht ist alles was er nutzt auf dem aktuellsten Stand, und er weiß auch warum.
An manchen Aussagen und Argumenten ist halt doch immer wieder zu lesen
Irgendwie drehen wir uns hier im Kreis.
Was nutzt es einem Anwender wenn Deine exe Datei im FHEM auf nem Raspi oder einer Fritzbox liegt? Gar nichts.
Also ist es doch angenehm wenn der Anwender auf seinem Windows PC FHEM im Browser aufruft, in die Detailansicht eines Devices von deinem Modul geht und dort auf Download WinConnect.exe drückt. Wobei sie auch gleich noch zur Installation angeboten wird. Der Download Link führt zum FHEM Contrib SVN wo Du immer die aktuellste Version ablegen kannst.
Ich begreife diese ganze Diskussion nicht mehr.
Zitat von: Sidey am 29 Juli 2017, 10:45:51
Damit meine ich jetzt nicht, einfach einen HTTP Aufruf abzusetzen, das kriege ich schon noch hin, nein vielmehr ist es ja so, dass man den Update Mechanismus zum einen nonBlocking implementieren sollte und zum anderen den Anwender auch geeignet abholen muss. Sonst macht der ja nur das altbekannte Update und gut ist.
Guck mal hier, das geht schon. https://forum.fhem.de/index.php/topic,39124.msg312783.html#msg312783
Aber wie schon gesagt, man muss halt das Rad noch mal erfinden. ;)
Zitat von: CoolTux am 29 Juli 2017, 10:59:30
Irgendwie drehen wir uns hier im Kreis.
Was nutzt es einem Anwender wenn Deine exe Datei im FHEM auf nem Raspi oder einer Fritzbox liegt? Gar nichts.
Also ist es doch angenehm wenn der Anwender auf seinem Windows PC FHEM im Browser aufruft, in die Detailansicht eines Devices von deinem Modul geht und dort auf Download WinConnect.exe drückt. Wobei sie auch gleich noch zur Installation angeboten wird. Der Download Link führt zum FHEM Contrib SVN wo Du immer die aktuellste Version ablegen kannst.
Ich begreife diese ganze Diskussion nicht mehr.
Es geht darum dass das ein Anwender der kaum Ahnung hat damit seine Schwierigkeiten hat. Ist nun mal so. Wir, die hier gerade diskutieren haben mit so etwas keine Probleme. Des weiteren haben die Anwendung sicherlich mehr als nur einen PC. Jetzt das ganze wieder auf manuell zurückdrehen macht auch keinen Sinn.
Die winconnect.exe kann von Haus aus schon ein automatisches Update durchführen, wenn auf dem FHEM Server die Datei in einem entsprechenden Verzeichnis liegt. Es war aus meiner Sicht also alles schon vorhanden. Fehlte nur noch der Schritt die EXE auf dem FHEM Server aktuell zu halten.
Gesendet von iPhone mit Tapatalk
Dann bleibt also nur weiter Diskutieren, die WinConnect exe für SVN Download anpassen oder eigene Wege gehen.
Sag Bescheid wenn Du Dich entschieden hast. Die FHEM Community hat Dir meiner Meinung nach eine akzeptable Möglichkeit geboten.
Zitat von: CoolTux am 29 Juli 2017, 12:39:45
Dann bleibt also nur weiter Diskutieren, die WinConnect exe für SVN Download anpassen oder eigene Wege gehen.
Sag Bescheid wenn Du Dich entschieden hast. Die FHEM Community hat Dir meiner Meinung nach eine akzeptable Möglichkeit geboten.
Meine Entscheidung ist schon lange gefallen! Trotzdem wollte ich meine Meinung dazu noch mal klar stellen.