Perl Readonly / Debian

Begonnen von Wzut, 30 April 2020, 19:55:04

Vorheriges Thema - Nächstes Thema

Sidey

Zitat von: RichardCZ am 01 Mai 2020, 17:47:20
2. Irgendjemand muss das ja dann auch warten, sonst haben "wir" im Repo eine Asbach-Uralt

Da würde ich bestimmt zu tendieren einmal im Monat die letzte Version aus der Quelle zu laden. Das mit 1x im Monat ist einfach aus dem Bauch heraus so gesagt.
Wobei ein brauchbares Interface aus FHEM heaus würde meiner Ansicht nach auch ausreichen. Die Idee das über das META Modul zu machen gefällt mir auch und über den Update Befehl könnten prinzipiell auch vorhandene CPAN Module mit aktualisiert werden.

Es gibt ja sogar Schnittstellen, die man einbinden könnte, ob sich da auch ein Zielverzeichnis angeben lässt habe ich nicht näher untersucht.
https://metacpan.org/pod/CPAN

Wenn der Wille da ist, wird sich auch sicher ein Weg finden.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

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

RichardCZ

Zitat von: Sidey am 01 Mai 2020, 18:52:20
Es gibt ja sogar Schnittstellen, die man einbinden könnte, ob sich da auch ein Zielverzeichnis angeben lässt habe ich nicht näher untersucht.
https://metacpan.org/pod/CPAN

Wenn der Wille da ist, wird sich auch sicher ein Weg finden.

$ ./updatecheck
File                                                         Local       CPAN
Hash::Case                                                    1.03       1.05
Hash::Case::Lower                                             1.03       1.05
Hash::Case::Preserve                                          1.03       1.05
Hash::Case::Upper                                             1.03       1.05


Ist jetzt leider Firmencode, kann den also nicht hier komplett abladen, aber auch nicht Hexerei, nutzt im Wesentlichen CPAN.

   find(\&_find_package_names, "$path/");   # Recursive checking for .pm files results storing in %$packages
...
    for my $module (@$list) {                                         # inspect all modules in dir
        for my $mod (CPAN::Shell->expand('Module', $module)) {        # expands submodules
            next if ($mod->uptodate());                               # no need to update -> check next

            my $name = $mod->id();
            my $installed = (!defined $mod->inst_version || $mod->inst_version eq 'undef') ? next : $mod->inst_version;
            my $available = (!defined $mod->cpan_version || $mod->cpan_version eq 'undef') ? '-'  : $mod->cpan_version;

            push @$updates, [$name, $installed, $available];
        }
    }

Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Wzut

oh je da habe ich ja wieder was angefangen ... mir ist nicht in Erinnerung auf meinem Test Rapi extra was mit Readonly installiert zu haben.
Da es aus dem Stand aber ging bin ich davon ausgegangen das es fester Bestandteil einer normalen Debian/Raspbian Installation ist und dieses Zusatzpaket ein Problem fixt.
Anyway ich kann es verstehen das man sich die Mühe machen muß ein CPAN Modul extra zu installieren wenn dessen Funktion zwingend für das Modul erforderlich ist und man es nicht mit ein paar Zeilen Code nachbilden kann. Beispiel war früher mal Net::SIP , das was da mit wheezy ausgeliefert wurde war nicht zu gebrauchen. D.h. wollte der User das Modul nutzen musste er wohl oder übel sich eine aktuelle Version holen. Wer mag kann ja mal im FB Unterforum suchen was das für die Mehrheit der User für ein Drama war.

Aber back to Topic : wenn Readonly so rausfällt bleibt ja doch noch der Weg via use constant in eine ähnliche Richtung zu gehen. Oder sehe ich hier wieder etwas falsch ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

RichardCZ

Man wird vielleicht gemerkt haben, dass ich in einigen Belangen ruhiger geworden bin, weil mich mittlerweile viele Sachen in FHEM nicht mehr per se aufregen, sondern ich einfach nur noch mit dem Kopf schüttele. Abgesehen davon habe ich ja mein HoBo-Ventil.

1) Man lege in der Projektroot ein Verzeichnis "lib" an.
2) in fhem.pl füge man dem use lib '.'; noch ein use lib 'lib'; hinzu
3) man kopiere einfach Readonly.pm nach lib und füge beides dem Repo hinzu
4) man füge dieses Verzeichnis in filelist von fhemupdate.pl mit ein

fertig.

Eventuell kann man das auch mit anderen Modulen machen:

https://gl.petatech.eu/root/HomeBot/-/tree/master/lib

optional könnte man dann auch die FHEM/lib Zombies updaten und nach lib ziehen.
und ganz eventuell kann man auch gleich ein t Verzeichnis nebendran legen und mal anfangen da was reinzuschreiben.

Zitate aus Glückskeksen zum Beispiel.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Sidey

Tia, ein Lösungswege ist aufgezeigt.

Das ganze lässt sich auch noch ausbauen.

Nun die Spannende Frage.
Fügen wir CPAN Module unter gewissen Bedingungen so ein?
Ich hätte da durchaus noch weitere Vorschläge, was sich anbieten würde.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

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

Christoph Morrison

Der ein oder andere hat ja schon bemerkt, dass ich bei Buienradar in den neueren Versionen Readonly verwende. Ich finde es nicht zu viel verlangt, die README und/oder Release-Notes zum Modul zu lesen bevor man es einbindet und sich selbst einen Weg - wenn man cpan / cpanm nicht nutzen möchte und / oder das Debian nicht nutzen kann oder möchte - sucht wie man Readonly an den Start bekommt. Wo genau hört eigentlich die Veratwortung für eine Installationsbasis für einen Modul-Maintainer auf bzw. wo fängt sie an?

Wenn sich jemand im Core dazu entscheidet, CPAN-Pakete mit auszuliefern fände ich das auch völlig opportun und dann sollte es halt einen Maintainer/Janitor für sowas geben (Integrations-/Regressionstests wären auch nett). Ich wette, es wäre eh keine besonders lange Liste und wir würden vielleicht ein paar Redundanzen in den Modulen los.

Wzut

@CM, wenn ich ein neues Modul schreibe und den Leuten sage "dafür müsst ihr aber Wzut::Blub  von CPAN installieren" werden die User das auch ohne Murren tun.
Wenn ich aber ein ein seit Jahren benutzes Modul " nur" update und von heute auf morgen wird  Wzut::Blub fällig dann wird das Geschrei groß sein.
Frei nach dem Motto "wieso , es lief doch jetzt bei mir seit Jahren und plötzlich muß ich alles ändern .....  Ich bin kein Linux Experte ... wo gibt es eine Schritt für Schritt Anleitung .... die Installation via CPAN schlägt bei mir fehl ....." Sucht euch was davon aus, IMHO haben wir das alle (Richard ausgenommen) hier schon genau so in der einen oder anderen Form so erlebt. Und wie Rudi darüber denkt CPAN Module auf den SVN zu packen sollte auch bekannt sein.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Christoph Morrison

Zitat von: Wzut am 03 Mai 2020, 07:16:23
@CM, wenn ich ein neues Modul schreibe und den Leuten sage "dafür müsst ihr aber Wzut::Blub  von CPAN installieren" werden die User das auch ohne Murren tun.
Wenn ich aber ein ein seit Jahren benutzes Modul " nur" update und von heute auf morgen wird  Wzut::Blub fällig dann wird das Geschrei groß sein.

Ja mag sein, aber irgendwann muss man halt auch mal alte Zöpfe abschneiden. Um das zu mitigieren gibt es Versionierung, d.h. ein User kann sich entscheiden, dass er z.B. bei 2.0 ohne Readonly bleibt, bekommt dann halt aber auch die tollen neuen BarCharts oder Bugfixes nicht. Oh, das geht bei FHEM Core nicht ohne Verrenkungen mit exclude, Kopierorgien oder Pflege eines Parallel-Repositories oder was auch immer? Pity, dann macht man halt kein update mehr und alles bleibt alt.

Zitat von: Wzut am 03 Mai 2020, 07:16:23
Und wie Rudi darüber denkt CPAN Module auf den SVN zu packen sollte auch bekannt sein.

Das Resultat aus dieser Argumentation ist, dass man jede Menge Code (ggf. minderwertig) dupliziert um jemand kein cpanm Readonly zuzumuten. Finde ich einen schlechte Deal, auch für die User.

Sidey

Ich bin da ganz der Meinung von WZut.

Es ist Anwender Unfreundlich wenn nach einem Update auf einmal der Kram nicht mehr geht.
Wer hätte das noch nicht, Sonntags noch schnell ein Update gemacht und am nächsten Tag wundert man sich, dass auf einmal keine Jalousien mehr fahren.
Das muss ja nicht so sein.

Wenn man als Entwickler die Anwender schonend vorbereiten möchte, kann man erst mal Warnung ausgeben oder featurelevel versenden. Denn wenn man es schlecht macht, kann Fhem sogar crashen.

Und wieso? Weil es a) keine Option gibt einfach ein CPAN Modul dem Anwender zur Verfügung zu stellen und b) auch keine Option akzeptiert wurde, im Update Prozess Referenzen einzupflegen.

Ich verstehe halt nicht, was dagegen spricht so ein cpan Modul bei Bedarf mit zu installieren.
Und wenn es gute Gründe gibt, es nicht ins SVN zu legen, dann lege ich ein git Repo an und lade benötigt cpan Module dort ab.
Ein kleiner Patch im Update.pm und die Module würden dann automatisch von dort aktualisiert werden.
Meinetwegen kann man es auch über META .PM laufen lassen.

Bevor ich hier Zeit investiere, hätte ich aber gerne ein paar Informationen unter welchen Bedingungen der Patch eine Chance hat.


Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

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

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

Christoph Morrison

Zitat von: Sidey am 03 Mai 2020, 13:52:14
Es ist Anwender Unfreundlich wenn nach einem Update auf einmal der Kram nicht mehr geht.
Wer hätte das noch nicht, Sonntags noch schnell ein Update gemacht und am nächsten Tag wundert man sich, dass auf einmal keine Jalousien mehr fahren.
Das muss ja nicht so sein.

"Sonntags noch schnell ein Update" ist halt eine sehr sehr risikobehaftete Update-Strategie, insbesondere wenn die Frau quängelt, wenn sie morgens dann im Dunklen sitzt und kein Licht mehr wie erwartet schaltet. Zumal man das bei einem ordentlichen Versionierungssystem einfach umgehen kann, in dem man halt ein fixes Release abonniert, wenn man überhaupt kein Risiko eingehen will bzw. manuell ein höheres Release auswählt. Meine Versionierungsstrategie stellt sicher, dass sowas wie "Readonly" nur in einem Major-Release geändert wird. Schaut euch mal Semantic versioning an.

ceterum censeo wäre es mir aber auch recht, wenn man einfach sagen könnte: Ok, BR will in 3.0 nun Readonly, JSON und Foobaz, also referenziere ich das in der Controls und FHEM sorgt dann dafür, dass Readonly, JSON und Foobaz auf dem System landet. Jeder der Perl hat, hat auch cpan.

rudolfkoenig

ZitatJeder der Perl hat, hat auch cpan.
Aber nicht unbedingt einen (dazu passenden) Compiler, und manche bevorzugen Perl-Module ueber OS-Pakete.
Gibt es eine Moeglichkeit aus dem Perl-Modulnamen den OS-Paketnamen zu berechnen?

Idealerweise laeuft das so ab:
- vor dem ersten Definieren eines Moduls prueft FHEM, ob alle CPAN-Module vorhanden sind, und installiert diese auf Benutzer-Aufforderung.
- update warnt, falls neue Abhaengigkeiten fuer verwendete Module existieren, und installiert sie auf Benutzer-Aufforderung, alternativ setzt sie das Modul auf ignoreList oder verweigert das update (je nachdem, ob das alte Modul noch kompatibel mit dem Rest ist).
- Modul-Installation laeuft entweder ueber CPAN oder ueber OS-Paket, jenachdem, was der Benutzer spezifiert hat.
- es gibt eine Moeglichkeit fuer update der CPAN-Pakete
- Pluspunkte gibt es fuer optionale Pakete, z.Bsp. wenn ein Calendar-Modul auch SAP abfragen kann, falls man das passende Perl-Modul installiert hat, was aber SAP-Bibliotheken benoetigt, und 99.9% der Anwender nicht braucht.

Das fehlerfrei fuer mehrere Betriebsysteme zu implementieren ist eine Herausforderung, ich erinnere mich noch an meinem Versuch mit cpan IO::Socket::SSL mit dem richtigen(!) openssl Bibliothek zu installieren.

Ich bin bereit optionale Hooks fuer LoadModule und update einzubauen, wenn irgendwer meint, die Aufgabe implementieren _und_ supporten zu koennen.

RichardCZ

Zitat von: rudolfkoenig am 03 Mai 2020, 14:52:26
Das fehlerfrei fuer mehrere Betriebsysteme zu implementieren ist eine Herausforderung,

Ich zappel schon seit gestern das wenigstens distri-unabhängig für Linux hinzubekommen. (AppImage)

Mittlerweile bin ich vom 100sten ins 1000ste gekommen: https://gl.petatech.eu/root/linuxdeploy-plugin-perl

Wenn das klappt, dann sollte die Sache zumindest für Linux gegessen sein. Also alles. Perl-Version, Module, optionale Binaries...
Wird dann zwar ein riesiger Blob, aber bis 100MB wäre es das wert - denke ich.

Wenn man das dann für x86 und ARM hat (wobei ein halbes Königreich für den, der mir zeigt wie ich unter Proxmox eine "RasPi-VM" aufsetze), sollte das reichen.

Stand Perl-only, 20MB ist also noch etwas Luft.

20M May  3 15:43 linuxdeploy-plugin-perl-x86_64.AppImage

Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

RichardCZ

$ HomeBot-x86_64.AppImage
Can't locate HoBo.pm in @INC (you may need to install the HoBo module) .....


Mittlerweile bin ich für die Wiedereinführung von Menschenopfern, aber ja, es geht langsam vorwärts.

41M May  3 22:12 HomeBot-x86_64.AppImage

Perl + Projektsourcen/Daten 41MB

Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

herrmannj

Richard, verstehe ich das richtig dass du einen installer für cpan Module schreibst der distri unabhängig cpan Module beim Benutzer, ohne Benutzereingriff installiert? Wenn ja, finde ich wertvoll! Muss aber rocking solid und bulletproof sein. Linux Recht imho


RichardCZ

Zitat von: herrmannj am 03 Mai 2020, 22:38:55
Richard, verstehe ich das richtig dass du einen installer für cpan Module schreibst der distri unabhängig cpan Module beim Benutzer, ohne Benutzereingriff installiert? Wenn ja, finde ich wertvoll! Muss aber rocking solid und bulletproof sein. Linux Recht imho

Ne - selber schreiben ... so wahnsinnig bin ich auch wieder nicht.

Ich versuche einen real existierenden anzuwenden: https://appimage.org/

Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.