Binaerdateien per update verteilen

[herrmannj]

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.

[betateilchen]

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.

[herrmannj]

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.

[mahowi]

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.

[rudolfkoenig]

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

[herrmannj]

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.

[rudolfkoenig]

Die 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

[betateilchen]

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

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

[rudolfkoenig]

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

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.

[betateilchen]

Es war nur ein Eintrag für den Merkzettel für das neu zu schreibende Modul 

[herrmannj]

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

[Sidey]

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

[michael.winkler]

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.

[rudolfkoenig]

Das war ja auch nicht die Idee, sondern dass man einen Ablageplatz hat, wo bei Bedarf diese Datei "online" heruntergeladen werden kann.

[betateilchen]

@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

Code Auswählen Erweitern


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

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.