Wie mit neuen Abhängigkeiten in bestehendem Modul umgehen?

[Thorsten Pferdekaemper]

Hi,
ich bin heute darauf Aufmerksam gemacht worden, dass die neue Version meines HM485-Moduls von den Perl Module XML::Simple und XML::SAX oder XML::Parser abhängt. Außerdem sieht es so aus, dass diese Module bei einer FHEM Installation nicht zwangsläufig vorhanden sind. Das ist jetzt natürlich ein bisschen blöd, weil dadurch ein "update" zu Problemen führt. Kann ich dagegen etwas tun?

(Details auch hier: https://forum.fhem.de/index.php/topic,70528.msg628922.html#msg628922)

Gruß,
    Thorsten

[Markus M.]

Zum Beispiel, in dem du im Modul selbst die Abhängigkeiten überprüfst und das einigermassen sauber abfängst, ohne dass das Modul nicht geladen wird und den Nutzern die komplette Config zerschiesst.

Code Auswählen Erweitern

  my $req = eval
  {
    require Crypt::CBC;
    Crypt::CBC->import();
    require Digest::MD5;
    Digest::MD5->import();
    1;
  };
  if(!$req)
  {
    $hash->{STATE} = "Crypt::CBC and Digest::MD5 are required!";
    $attr{$name}{disable} = "1";
    return undef;
  }


[Thorsten Pferdekaemper]

Hi,
ok, das hilft schon einmal gegen reflexhaftes "Save config" drücken. Allerdings muss man ja schon ziemlich schusselig sein, wenn es nach einem Update Fehlermeldungen hagelt und Devices fehlen und man dann erst einmal "Save config" drückt. (Oder verstehe ich da was falsch?)
...und außerdem funktioniert die ganze Sache dann nach dem update trotzdem nicht.
Ich hatte eher an etwas gedacht wie das update zu verhindern, wenn bestimmte Bedingungen nicht gegeben sind. Das geht aber wahrscheinlich nicht.
Gruß,
    Thorsten

[rudolfkoenig]

Nach einem eval frage ich lieber $@ ab, ob es gesetzt ist. Falls ja, dann liefere ich das zurueck bzw. protokolliere es im Log. Im vorherigen Beispiel wuesste damit der Benutzer, welche der beiden Module das Problem verursacht.

[Thorsten Pferdekaemper]

Nach einem eval frage ich lieber $@ ab, ob es gesetzt ist. Falls ja, dann liefere ich das zurueck bzw. protokolliere es im Log. Im vorherigen Beispiel wuesste damit der Benutzer, welche der beiden Module das Problem verursacht.

Das weiß der Benutzer sowieso schon, wenn er ins Log schaut. Da steht explizit "you may need to install the XML::Simple module".
Ich suche nach einer Möglichkeit, das Problem gar nicht erst auftreten zu lassen.
Gruß,
   Thorsten

[Markus Bloch]

Das kannst Du nicht direkt. Man kann entweder wie Rudi gesagt hat das Laden eines Moduls per eval testen. Wenn es nicht geladen werden kann, wird $@ mit der Fehlermeldung gesetzt.

Eine automatische Nachinstallation per cpan ist nicht möglich.

Alternativ versuchen das FHEM-Modul ohne  die Modulabhängigkeit implementieren. Das ist aber nicht immer so ohne weiteres möglich.

Ich würde an Deiner Stelle ebenfalls das Modul per eval in der DefineFn laden. Sollte das Modul nicht zur Verfügung stehen gibt die DefineFn eine entsprechende Fehlermeldung zurück. Die wird beim Start im Logfile protokolliert bzw. bei manueller Eingabe.

Gruß
Markus

[igami]

könnte man das Modul nicht einfach dann auf diabled setzen und den Fehler in den state schreiben oder so?

[Thorsten Pferdekaemper]

Hi,
danke für die Vorschläge, aber das hilft ja wie gesagt nicht wirklich. Das Ergebnis ist fast dasselbe wie nichts tun: Nach dem Update funktioniert nichts mehr. Ob noch eine schönere Meldung ausgegeben wird und ob jetzt die Geräte nicht mehr vorhanden sind oder ein bestimmtes Attribut gesetzt wird, halte ich für marginal.
Meiner Meinung nach ist es etwas unschön, dass man ein update nicht stoppen kann, wenn man schon vorher genau weiß, dass es zu Problemen führen wird. Das Update wird ja auch zurückgerollt, wenn etwas mit einer Datei nicht stimmt.
Wenn ich mit apt ein Paket installieren will, für das die Abhängigkeiten nicht gegeben sind, dann geht das ja auch nicht ohne weiteres.
Vielleicht könnten wir da mal was machen.
Gruß,
    Thorsten

[Markus Bloch]

Hi Thorsten,

Das ist generell eine gute Idee, gestaltet sich aber in der Praxis als äußerst schwierig. Gerade bei Perl-Modulen, welche kompiliert werden müssen, muss sichergestellt werden, das alle benötigten Tools (Compiler, Make, ...), sowie alle Header-Files der entsprechenden Libaries vorhanden sind. Hier ist leider der User in der Pflicht sich drum zu kümmern.

Es gibt in FHEM die Möglichkeit reine Perl-Module welche nicht kompiliert werden müssen, via Update mitzuliefern. Einige Module gibt es in kompilierte Form zwecks Performance (ich glaube die Module mit dem Zusatz "XS", bin mir da gerade nicht ganz sicher), als auch in reinem Perl-Code. Hier kann man gezielt auf kompilierte Abhängigkeiten verzichten. Solche Module könnte man dann via update mit ausliefern, sofern Rudi dem zustimmt. Dafür gibt es den Ordner FHEM/lib

Viele Grüße

Markus

[chris1284]

ich sags mal einfach ohne zu wissen ob technisch möglich: man müsste die fhem updatefunktion erweitrern das sie abhängigkeiten aus den modulen ließt (zb use Date::Parse;) und vor dem herunterladen versucht das perl module zu laden/ schauen ob es vorhanden ist. wenn das nicht geht, wird das update des modules nicht geladen und ein meldung ausgegeben (und natürlich das update wieter durchgeführt).

perl-module zu installieren ist dann wieder usersache und das aktuelle modul wird solange nicht geladen bis die abhänhigkeiten erfüllt sind.

[rudolfkoenig]

Vorschlag: Falls waehrend der Initialisierung ein Modul nicht geladen werden kann, dann wird die Definition einem "Platzhalter" Modul zugewiesen, und damit sichergestellt, dass die Daten aus fhem.cfg nicht verloren gehen. Falls jemand damit ein Problem sieht, bitte melden.

@chris1284: Um es richtig zu machen, muesste update den Modulcode ausfuehren, was etliche Nebeneffekte haben kann, unter anderem, dass update nie fertig wird (siehe Halteproblem). Eine vereinfachte Variante (Code nicht ausfuehren, nur nach use und require in bereits verwendeten Modulen suchen) hilft nicht: Das FHEM ZWave Modul unterstuetzt optional Verschluesselung, wenn man Crypt::Ryjndael installiert hat. Viele haben das nicht installiert, brauchen es aber auch nicht.

[Thorsten Pferdekaemper]

Das ist generell eine gute Idee, gestaltet sich aber in der Praxis als äußerst schwierig.

Ich hatte mir so etwas wie einen Pre-Update-Hook vorgestellt. D.h. ein Verzeichnis, in das Modulautoren eine Datei mit einer Prüfroutine ausliefern können. Nur wenn alle Prüfungen erfolgreich durchlaufen werden, wird das Update beendet, ansonsten zurückgerollt. (So wie momentan auch bei der Prüfung der Dateigröße.)
Sooo schwierig scheint mir das nicht.   

Es gibt in FHEM die Möglichkeit reine Perl-Module welche nicht kompiliert werden müssen, via Update mitzuliefern.

Ich fände es etwas hässlich, XML::Simple und ähnliches mit FHEM selbst auszuliefern.

ich sags mal einfach ohne zu wissen ob technisch möglich: man müsste die fhem updatefunktion erweitrern das sie abhängigkeiten aus den modulen ließt (zb use Date::Parse;)

Meiner Meinung nach bringt's das nicht, da ja nicht alle Module gleich gar nicht funktionieren, wenn eine Abhängigkeit fehlt. Außerdem würde mein Modul dann wahrscheinlich gar nicht mehr gehen, da manche Abhängigkeiten erst bei der Initialisierung generiert werden.
Ich denke, nur das Modul selbst kann wissen, was es wirklich braucht.

(und natürlich das update wieter durchgeführt).

Nein, genau das nicht. Dadurch wírd entweder das problematische Modul deaktiviert (was ja genau mein Problem ist) oder es wird eine alte Version in einem neuen FHEM verwendet. Das würde auch Probleme machen.

perl-module zu installieren ist dann wieder usersache und das aktuelle modul wird solange nicht geladen bis die abhänhigkeiten erfüllt sind.

Wie gesagt, genau das ist ja das Problem, was ich vermeiden will.

Vorschlag: Falls waehrend der Initialisierung ein Modul nicht geladen werden kann, dann wird die Definition einem "Platzhalter" Modul zugewiesen, und damit sichergestellt, dass die Daten aus fhem.cfg nicht verloren gehen. Falls jemand damit ein Problem sieht, bitte melden.

Ich sehe damit kein Problem, aber es würde für mich keinen Unterschied machen. Es nützt nur etwas gegen das reflexhafte "Save config", aber nach dem Update funktioniert trotzdem nichts mehr.
Also bitte das nicht für mich einbauen, ich brauche es nicht.

Ich werde es jetzt wahrscheinlich so machen, dass ich das ganze einfach mal in "meine" Standardauslieferung schiebe, vorher aber Warnungen im Forum ausgebe. Bei den meisten dürfte XML::Simple sowieso installiert sein und der Rest klickt hoffentlich nicht gleich auf "Save config" oder hat ein Backup.

Gruß,
   Thorsten

[rudolfkoenig]

Ich sehe damit kein Problem, aber es würde für mich keinen Unterschied machen. Es nützt nur etwas gegen das reflexhafte "Save config", aber nach dem Update funktioniert trotzdem nichts mehr.

Ok, dann nicht. Btw. update legt automatisch eine Kopie von fhem.cfg im jeweiligen restore Unterverzeichnis an.

[CoolTux]

Ok, dann nicht. Btw. update legt automatisch eine Kopie von fhem.cfg im jeweiligen restore Unterverzeichnis an.

Das wäre gerade meine Idee gewesen, einfach eine Kopie der cfg machen.
Problem!!! Die Experten mit ihren include cfg's. Aber meine Meinung dazu kennt Ihr ja.



Grüße

[Thorsten Pferdekaemper]

Ok, dann nicht. Btw. update legt automatisch eine Kopie von fhem.cfg im jeweiligen restore Unterverzeichnis an.

Das ist auf jeden Fall beruhigend.

Das wäre gerade meine Idee gewesen, einfach eine Kopie der cfg machen.
Problem!!! Die Experten mit ihren include cfg's. Aber meine Meinung dazu kennt Ihr ja.

Ich denke, dass ich damit leben kann. Das macht im Endeffekt echte Probleme relativ unwahrscheinlich, da folgendes zusammenkommen muss:

• Upgrade (d.h.) Verwendung von HM485 (HM-Wired)
• XML::Simple nicht installiert
• "Save config" gedrückt trotz Problemen
• fhem.cfg-Editierer

Ich glaube, dass ich wagen kann, das auf die Verwender loszulassen.

Danke&Gruß,
    Thorsten