Binaerdateien per update verteilen

Begonnen von rudolfkoenig, 22 Juli 2017, 20:00:27

Vorheriges Thema - Nächstes Thema

Sidey

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rudolfkoenig

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.

betateilchen

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

Sidey

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rudolfkoenig

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.

betateilchen

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

michael.winkler

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!

herrmannj

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

michael.winkler

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

CoolTux

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

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

rudolfkoenig

Hast du einen konstruktiven Vorschlag?
Ich wuesste auch gerne, wieviele direkt per "svn update" aktualisieren.

herrmannj

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

betateilchen

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

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

betateilchen

#44
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)

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