frage zum update von fhem

the ratman · 04 Juni 2019, 09:38:27

ist mir nur grad so durch den kopf geschossen ... vielleicht findets ja ein developer toll genug für eine kleine bastelstunde *g*:

wäre es nicht schön, hätte man bei der update-prüfung eine info, welche version eines moduls man benutzt und welche man kriegt?
und als goody am ende ein häckchen, dass man wegmachen kann, wenn man dieses modul nicht updaten möchte.

grund für den irrsinn:
ersteres würds doch sehr erleichtern zu sehen, was sich so tut und man könnte - hätte man z.b. länger nicht upgedatet - so aufgrund der x neuen versionen nachverfolgen, was sich da alles neues getan hat.
zweiteres wäre einfach nur eine kleine hilfe um mal module kurzfristig und ohne das gleich wo eintragen zu müssen, vom update auszugrenzen. bspl. wäre da der zur zeit "schwebende bug" bei hue. schreibt man die module wegen - vielleicht 2 tagen - in die ausnamen und vergisst sie dort dann eventuell, oder mach man halt ein paar mal 2 häckchen in der früh weg ...

CoolTux · 04 Juni 2019, 09:43:19

Bitte beachten! Es gibt keine wirkliche Version sondern lediglich eine Revision. Bei jedem Commit im SVN ändert sich diese für das jeweilige comittete (was für ein Wort) Modul.
In wie weit das für den Enduser nützlich ist vermag ich aber nicht zu beurteilen.

the ratman · 04 Juni 2019, 09:49:29

naja, ich hätte aber zumindest 2 datum - mein aktuelles und das des neuesten moduls. kann man sicher auch so zusammen suchen, aber wär halt einfach an ort und stelle. damit grenz ich mir meinen zeitraum ein und find sicher leichter was.

grundlegend gehts mir eh mehr um das häckchen. ich wollts nur ein bissi versteckter anbringen, damit die nur-cli-ist-was-für-echte-männer-leute nicht gleich wieder klicki-bunti-alarm ausrufen *bg*

Beta-User · 04 Juni 2019, 09:54:44

Ähm, die Revisions-Nummer ändert sich mit jedem commit, ganz gleich, welches Modul/welche Dateien betroffen sind.

MaW: wenn man wissen will, was an einem Modul geändert wurde, muß man derzeit das svn bemühen, alos z.B. auf diese Weise: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/52_I2C_SHT21.pm?rev=11728 und dann "Vorige/Letzte/Nächste Revision" auswählen...

Und Obacht: Manchmal wird ein ganzer Satz Dateien auf einmal geändert; schließt man eine davon aus, kann das "seltsame" Nebenwirkungen haben

. Der "steinige" Weg via excludefromupdate ist vermutlich daher weiter besser als eine "wilde" Userkonfiguration, die zu endloser Fehlersuche führen könnte (jedenfalls im meiner Phantasie

).

CoolTux · 04 Juni 2019, 10:00:27

Zitat von: Beta-User am 04 Juni 2019, 09:54:44
Ähm, die Revisions-Nummer ändert sich mit jedem commit, ganz gleich, welches Modul/welche Dateien betroffen sind.

Eigentlich nicht. Die Revisionsnummer für das Modul bleibt gleich auch wenn andere Module mit neuerer Revision eingecheckt werden. Schau mal mit version im FHEM WEB. Da hat jedes Modul eine andere Revisionsnummer.
Oder habe ich Dich gerade falsch verstanden?

Beta-User · 04 Juni 2019, 10:05:28

Das war so gemeint: die Revisionsnummer, die im Modul wiedergegeben ist (und per version abgefragt werden kann) ist nicht alleine für das Modul fortlaufend (also letzte Revision = vorige Revision + 1), sondern erhöht sich mit jedem commit, egal, welches Modul betroffen ist.
Wenn du also von Rev. 10000 eines Moduls auf Rev. 19500 erhöhst, weißt du nicht, wieviele der Zwischencommits das Modul betreffen. Das war aber die Info, die the ratman eigentlich haben wollte, wenn ich das "aufgrund der x neuen versionen" richtig verstanden hatte.

CoolTux · 04 Juni 2019, 10:08:46

Zitat von: Beta-User am 04 Juni 2019, 10:05:28
Das war so gemeint: die Revisionsnummer, die im Modul wiedergegeben ist (und per version abgefragt werden kann) ist nicht alleine für das Modul fortlaufend (also letzte Revision = vorige Revision + 1), sondern erhöht sich mit jedem commit, egal, welches Modul betroffen ist.
Wenn du also von Rev. 10000 eines Moduls auf Rev. 19500 erhöhst, weißt du nicht, wieviele der Zwischencommits das Modul betreffen. Das war aber die Info, die the ratman eigentlich haben wollte, wenn ich das "aufgrund der x neuen versionen" richtig verstanden hatte.

Ah jetzt verstehe ich. Ne das ist richtig, so wirklich sieht man da nichts.

the ratman · 04 Juni 2019, 10:09:26

nur, damits keine mißverständnisse gibt: zumindest mein "häckchen" soll ja nix anderes als ein temporäres exlude_from_update sein. reicht ja, wenn das anhand des gelöschten häckchens eingetragen wird, dann upgedatet wird und nach dem neustart is alles wieder beim alten, ich krieg morgen wieder das modul zum update angeboten, weils ja nicht gespeichert wurde.
sprich: exclude_from_update als totmannschalter *g*

und zum rest:
versteh ich das richtig? ich schau nach dem datum "meines" moduls in fhem und sollte anhand dieses datums nicht rauskriegen können, zu welchen anderen tagen welche sachen im modul verändert wurden? vielleicht irgend wann mal automatisiert aufgelistet bei bedarf. wäre geil zur fehlersuche, weil man dann wohl recht genau sagen könnte, welcher tag den übeltäter brachte.

Beta-User · 04 Juni 2019, 10:14:23

Nochmal: exclude_from_update sollte wegen des Charakters von FHEM als perpetual beta (mein Verständnis) sehr sparsam eingesetzt werden; es macht keinen Sinn, das komfortabel zu machen...

Die Änderungshistory zu einem Modul bekommt man auf dem hier beschriebenen Weg:

Zitat von: Beta-User am 04 Juni 2019, 09:54:44
MaW: wenn man wissen will, was an einem Modul geändert wurde, muß man derzeit das svn bemühen, alos z.B. auf diese Weise: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/52_I2C_SHT21.pm?rev=11728 und dann "Vorige/Letzte/Nächste Revision" auswählen...

Da gibt es dann auch die Option, den Changeset anzusehen: https://svn.fhem.de/trac/changeset/11728/

the ratman · 04 Juni 2019, 10:58:55

das is dann eh sinnlos für 08/15 user
weil das interessante daraus wäre z.b. wohl eh nur

Code Auswählen

Nachricht:
    52_I2C_SHT21: bugfix in crc
    00_RPII2C/10_FRM: added SHT.* clients

bringt eh nix. das müsste man dann wenigstens vom datum des laufenden moduls bis zum aktuellen irgendwie zusammenfassen.

aber von meinem "häckchen" rück ich mal nicht ab.
ich weiß ned, wie userfreundlich es ist, wenn du dann 3 wochen lang (<-- dramatisation gesponsert von pro7) jeden tag x häckchen weg klickst. es wäre halt nur einfacher, wenn du jetzt mal für 1 oder 2 tage nicht gleich wieder in - leicht zu vergessenden - attributen rumtippen mußt. und ja, ich weiß dass es bei jeden dummen update am anfang steht, aber ich weiß auch um die dummheit des menschen (eigenversuche) - noch verliert das universum nicht mal ansatzweise (belegt durch pro7) *g*.

btw - ne nette hilfe wäre zumindest mal, die ganze updateanzeige aus nur 1 pre-tag raus zu nehmen und nen eigenen tag für z.b. die ausgeschlossenen module zu machen. dann könnte man das zumindet farblich hervor heben.

Beta-User · 04 Juni 2019, 11:07:50

OK, das mit dem "Weghaken" ist jetzt auch bei mir angekommen - so könnte es ggf. gehen.

Wäre doch mal ein Projekt zum Perl-Lernen für dich, oder?
Aus einer simplen Text-Rückgabe (aus update check) ein Dialogfeld mit "Hakenfeldern" basteln...

Vielleicht würde das dann sogar eingeckeckt, wenn du es sauber als patch lieferst.

MadMax-FHEM · 04 Juni 2019, 11:12:43

Dann müsste aber auch mitprotokolliert werden, DASS und WAS excluded wurde...
...das müsste dann auch leicht abfragbar sein...

UND: es müsste/sollte gleich zu Beginn einer Frage/Problemstellung gespostet werden...

Sonst kann Unterstützung bei Fehlersuche echt mühsam werden (wenn man Fehler jagt, die es nur deswegen gibt)...
...bislang ist es eher Randerscheinung, da ja "mühsam", "manuell" per exclude-Eintrag gemacht werden musste...

Wenn es "so schick und einfach" geht ist die Frage wieviele Probleme kommen, "nur" weil ein Anwender etwas "abhakt" (nach dem Motto: das Modul hab ich doch gar nicht/verwende ich doch gar nicht)...

Nur so als "Einwurf"...

Gruß, Joachim

Beta-User · 04 Juni 2019, 11:19:45

Na ja, die (modifizierte?) Idee von the ratman war ja, den Anwender bei jedem update wieder dazu zu zwingen, das jeweils aktiv rauszunehmen, was er jetzt nicht updaten will. Einen massenhaften Gebrauch als Komfortfunktion sehe ich daher nicht (mehr), wenn und solange man das so ausgestalten würde.

(Aber der Weg zur Forderung, das dann zu verstetigen, ist sehr kurz).

(Aber generell: Evtl. wäre es sinnvoll, die Modulversion zukünftig grundsätzlich in list aufzuführen? Erspart ggf. blöde Rückfragen und noch blödere Reaktionen auf die Rückfrage...)

the ratman · 04 Juni 2019, 12:25:04

Zitat von: Beta-User am 11 Dezember 1974, 04:18:47~snip~Vielleicht würde das dann sogar eingeckeckt, wenn du es sauber als patch lieferst.

ich danke für deine unendliche überschätzung meiner person. aber: ich habs schon des öftern erwähnt ... programmiersprachen und ich sind grundlegende feinde. vorher heiratet meine katze nen hund, bevor ich mehr als 5 funzende zeilen zusammen kriege *g* ...

und ja, die idee war einfach: ich hacke teile des updates weg, diese werden einfach in die liste von "do not update" gelegt. mach ich dann sofort mein update greift das.
nach dem obligatorischen restart nach dem update ist die liste aber wieder auf "standard" zurück, weil ich ja in fhem vorher nicht abgespeichert hab.
theoretisch könnte ich so auch neue ausnamen fest einpflegen indem ich vor dem update speichere. aber ich denke, da weiß man eh, was man will.

Zitat(Aber generell: Evtl. wäre es sinnvoll, die Modulversion zukünftig grundsätzlich in list aufzuführen? Erspart ggf. blöde Rückfragen und noch blödere Reaktionen auf die Rückfrage...)

genau das ist mein ziel - wie immer - dem noob das leben vereinfachen und den programmierer weniger nerven ...

bitte in dem zusammenhang auch weiterhin im hinterkopf behalten: die update-liste aus nur einem pre aufteilen zwecks z.b. farblicher hervorhebung von "ausgenommen", "neu" und was immer sonst noch so möglich ist. dann hat mans auf einen blick, ob da eventuell zu viel in der update-sperre liegt.

Beta-User · 04 Juni 2019, 12:44:32

Zitat von: Beta-User am 04 Juni 2019, 11:19:45
(Aber der Weg zur Forderung, das dann zu verstetigen, ist sehr kurz).

Bereits einen Schritt weiter mit der Frage nach einer Speicheroption zu kommen, ist schon steil... Da bin ich definitiv DAGEGEN (aus den von Joachim und mir schon genannten Gründen!)

Zu Hunden und Katzen: manchmal friert die Hölle zu, ich habe schon Sachen erlebt... (U.A. habe ich hier vor Jahren mal behauptet, dass ich garantiert NIE zum Developer tauge

. Stimmt zwar wahrscheinlich - je nach Sichtweise - immer noch irgendwie, die Realität ist in Teilen eine andere. Also: Jeder Weg beginnt mit der ersten Samtpfote

. Du willst schließlich was haben, was andere nicht unbedingt für notwendig halten...

Und bgzl. der Idee, die revision in list mit aufzunehmen: Es gibt irgendwo eine Wunschliste, du bist doch sonst nicht so erschrocken

.