Fehlende Scripte in IPKs bei Plugins von Schwerkraft

  • Könnte bitte mal jemand schauen wieso beim bauen der Plugins von Schwerkraft die postrm, postinst, preinst usw. Scripte aus dem CONTROL Folder nicht in den IPKs landen. Könnt man das vielleicht mal fixen? :grinning_squinting_face:


    beispielsweise das epgbackup Plugin

    • Offizieller Beitrag

    Der Grund ist, dass die Skripte mehr Schaden als Nutzen bringen. In aller Regel wird darin wild an Enigma herumgepatcht oder etwas getan, für das es eine bessere Lösung gegeben hätte oder das der Paketmanager bereits abdeckt.


    Beispiel epgbackup:
    Das postinst-Skript installiert /usr/bin/enigma2_pre_start20epgrestore.sh, das postrm-Skript entfernt diese Datei wieder. Stattdessen sollte die Datei einfach ins Makefile.am eingetragen werden (bin_SCRIPTS = enigma2_pre_start20epgrestore.sh). Sie würde dann automatisch mit den richtigen Rechten ins richtige Verzeichnis (keine hardcoded Pfade!) installiert werden und bei der Deinstallation des Pakets automatisch entfernt werden.


    Übrigens haben diese enigma2_pre_*.sh-Skripts ab enigma 4.2 keine Funktion mehr. Stattdessen sollte man dort systemd unit files verwenden.

  • Der Grund ist, dass die Skripte mehr Schaden als Nutzen bringen. In aller Regel wird darin wild an Enigma herumgepatcht oder etwas getan, für das es eine bessere Lösung gegeben hätte oder das der Paketmanager bereits abdeckt.


    Beispiel epgbackup:
    Das postinst-Skript installiert /usr/bin/enigma2_pre_start20epgrestore.sh, das postrm-Skript entfernt diese Datei wieder. Stattdessen sollte die Datei einfach ins Makefile.am eingetragen werden (bin_SCRIPTS = enigma2_pre_start20epgrestore.sh). Sie würde dann automatisch mit den richtigen Rechten ins richtige Verzeichnis (keine hardcoded Pfade!) installiert werden und bei der Deinstallation des Pakets automatisch entfernt werden.


    Übrigens haben diese enigma2_pre_*.sh-Skripts ab enigma 4.2 keine Funktion mehr. Stattdessen sollte man dort systemd unit files verwenden.

    Die post-/pre-Methoden vom EPGBackup machen aber mehr als nur ein File erstellen. Wie könnte man commands nach einer Installation mit bin_SCRIPTS oder Ähnlichem ausführen?
    Ich gebe dir natürlich recht, dass Pfade hart codieren nicht der ideale Weg ist, aber im konkreten Fall wird er sich wohl nicht so schnell ändern (/usr/bin).
    Ich finde eine Richtlinie (nämlich das enigma-sourcen nicht gepatched werden sollen), müsste reichen. Deshalb eine Funktionalität nicht anzubieten finde ich nicht richtig. Wenn jemand wirklich unbedingt patchen will/muss, dann findet er auch andere Wege, also hat man keine Sicherheit gewonnen.

    • Offizieller Beitrag

    Stimmt das hatte ich vergessen du führst da ja einen Install Befehl mit dem Script aus.

    Es führt einen Befehl aus, und dieser installiert oben genanntes Script.


    Die post-/pre-Methoden vom EPGBackup machen aber mehr als nur ein File erstellen. Wie könnte man commands nach einer Installation mit bin_SCRIPTS oder Ähnlichem ausführen?
    Ich gebe dir natürlich recht, dass Pfade hart codieren nicht der ideale Weg ist, aber im konkreten Fall wird er sich wohl nicht so schnell ändern (/usr/bin).
    Ich finde eine Richtlinie (nämlich das enigma-sourcen nicht gepatched werden sollen), müsste reichen. Deshalb eine Funktionalität nicht anzubieten finde ich nicht richtig. Wenn jemand wirklich unbedingt patchen will/muss, dann findet er auch andere Wege, also hat man keine Sicherheit gewonnen.

    Der Rest des Befehls hat in unseren Images keine Funktion: Er erstellt einen Symlink in /usr/script, sofern das Verzeichnis existiert - was nicht der Fall ist. Übrigens als einziges Plugin auf Schwerkraft. Wenn das in einem fremden Image nötig ist, kann man auch erwarten, dass es dort angepasst wird. Plugins auf Schwerkraft sind in erster Linie für die Verwendung mit offiziellen Images vorgesehen. Leichte Anpassungen mitzutragen ist kein Problem, aber so etwas sprengt den Rahmen. Es lässt sich schlicht nicht nachvollziehen, welche Images, geschweige denn in welchen Versionen, diese Funktionalität nutzen. Aus meiner Sicht ist es unbenutzter Code.


    Zum Thema Pfade: /usr/bin bleibt /usr/bin, aber während der Entwicklung wird auf dem PC nicht in /usr/bin installiert. Plugins, die auf starre Pfade angewiesen sind, haben dadurch grundsätzlich eine geringere Testabdeckung.


    Noch etwas zu postinst-Scripts: Es gibt eben viele Fallstricke, über die man insbesondere im OE stolpern kann. Beispiele:
    - Postinst-Scripts müssen außerhalb der Box ("offline") ausführbar sein (und natürlich denselben Effekt erzielen), nämlich während der Erstellung des rootfs. Andernfalls hat es bei standardmäßiger Installation den Effekt, dass es beim ersten Booten ausgeführt werden muss, was das Booten verlangsamt.
    - Postinst-Scripts dürfen nicht exit aufrufen, da OE eigenen Code anhängen kann.
    - Postinst-Scripts sind abhängig von der OE-Version und darin vorhandenen Pfaden und Tools, und sie gehören daher ins Recipe statt ins Source-Repository. Plugins selbst sind hingegen - saubere Programmierung vorausgesetzt - nur von der Version von Enigma abhängig.


    Die Richtline lautet hier, keine Postinst-Scripts für Plugins auf Schwerkraft zu nutzen, und sie wird technisch durchgesetzt. Wer dennoch unbedingt ein Postinst-Script für sein Plugin braucht, kann es mittels eines eigenen Recipes ganz einfach anlegen, oder einen Patch für enigma2-plugins_*.bb schicken, der es dort hinterlegt. Mit guter Begründung natürlich und nur mangels besserer Möglichkeiten.

  • Ich wusste nicht, dass die Nichtverwendung auch eine Richtlinie ist. Somit ist es natürlich legitim, dass dies technisch sichergestellt wird :smiling_face:
    Das mit dem /usr/scripts habe ich als praktisch empfunden, und es ist ja auch ein eigenes Plugin, und nicht nur im Ozoon Image inkludiert. Aber es ist natürlich kein Muss.


    Ich werde bei Gelegenheit schauen, wie ich die hooks wieder los werde.