Funktionsumfang update / updatefhem

[Martin Fischer]

nach der untenstehenden auflistung der argumente, würde ich updatefhem wie
folgt ändern:

- umbenennen in 'update'

'update <svn|stable> [<file>|changed|fhem|pgm2]':

'update <svn|stable> fhem' - nur fhem aus fhemupdate3/<svn|stable>
'update <svn|stable> pgm2' - nur pgm2 aus fhemupdate3/<svn|stable>
'update <svn|stable> full' - fhem + pgm2 aus fhemupdate3/<svn|stable>
'update <svn|stable> <file>' - nur <file> aus fhemupdate3/<svn|stable>/<file>
'update <svn|stable> changed' - listet CHANGED aus fhemupdate3/<svn|stable>

'update <svn|stable>' - gibt hinweis auf fehlendes argument

egal welches update aufgerufen wird: 'backup' wird angestossen.

das ist nun mein vorschlag.

bleibt noch ein punkt:
die überlegung von rudi, das "www/" zu streichen sowie die svn struktur
anzupassen, hat unmittelbaren einfluss auf die obigen punkte. ggf. müssten wir
auch noch mal die "filetimes.txt" überdenken. entweder muss sie inhaltlich so
aufgebaut sein, das ich zu 100% zwischen fhem und pgm2 unterscheiden kann,
oder wir machen für jedes eine eigene. bei 'full' werden dann beide
abgearbeitet.

noch ein punkt fällt mir ein:
Am Mittwoch, 23. Mai 2012, 10:44:15 schrieb Rudolf Koenig:
> - wie verschieben wir Dateien mit updatefhem. Generische Loesung bevorzugt:
> ich will demnaechst XmlList/JsonList/updatefhem von 99 in 98 umbenennen,
> und es nur bei Verwendung laden.

wir könnten filetimes.txt verwenden und eine neue spalte spendieren:
2012-04-17_07:45:10 4362 FHEM/98_structure.pm
2012-03-04_13:26:44 828 FHEM/98_weblink.pm
2011-12-02_07:45:09 12952 FHEM/99_JsonList.pm FHEM/98_JsonList.pm
2011-11-12_08:54:54 8678 FHEM/99_SUNRISE_EL.pm
2011-11-12_08:54:54 828 FHEM/99_Utils.pm
2012-05-04_07:45:09 2657 FHEM/99_XmlList.pm FHEM/98_XmlList.pm
2012-05-21_07:45:09 13924 FHEM/99_updatefhem.pm FHEM/98_update.pm

in der letzten spalte stünde dann wie die datei neu heisst und ich könnte sie
dann moven. allerdings löst das nicht das problem, alte module bei einem
update zu löschen.

man könnte filetimes.txt zu einer art "steuerdatei" ausweiten und eine spalte
noch davor einfügen (DEL für löschen, MOV für umbenennen,--- keine
sonderbehandlung):

--- 2012-04-17_07:45:10 4362 FHEM/98_structure.pm
--- 2012-03-04_13:26:44 828 FHEM/98_weblink.pm
MOV 2011-12-02_07:45:09 12952 FHEM/99_JsonList.pm FHEM/98_JsonList.pm
--- 2011-11-12_08:54:54 8678 FHEM/99_SUNRISE_EL.pm
--- 2011-11-12_08:54:54 828 FHEM/99_Utils.pm
MOV 2012-05-04_07:45:09 2657 FHEM/99_XmlList.pm FHEM/98_XmlList.pm
DEL 2012-05-21_07:45:09 13924 FHEM/99_updatefhem.pm
--- 2012-05-21_07:45:09 13924 FHEM/98_update.pm

oder der zu löschenden datei in der filetimes.txt ein ".delete" anzuhängen:

2012-04-17_07:45:10 4362 FHEM/98_structure.pm
2012-03-04_13:26:44 828 FHEM/98_weblink.pm
2011-12-02_07:45:09 12952 FHEM/99_JsonList.pm FHEM/98_JsonList.pm
2011-11-12_08:54:54 8678 FHEM/99_SUNRISE_EL.pm
2011-11-12_08:54:54 828 FHEM/99_Utils.pm
2012-05-04_07:45:09 2657 FHEM/99_XmlList.pm FHEM/98_XmlList.pm
2012-05-21_07:45:09 13924 FHEM/99_updatefhem.pm.delete
2012-05-21_07:45:09 13924 FHEM/98_update.pm

mal so als ein paar ideen..


==> umbenennen von 'updatefhem' nach 'update':
Am Donnerstag, 31. Mai 2012, 20:03:36 schrieb Martin Fischer:
> 'updatefhem' suggeriert, das fhem aktualisiert wird. hinzu kommt: wenn ich
> heute ein fhem ohne pgm2 installiert habe, dann habe ich pgm2 nach einem
> 'updatefhem' automatisch auf der platte (obwohl ich mich ja vorher explizit
> dagegen entschieden habe).

==> parameter:
Am Freitag, 25. Mai 2012, 09:15:10 schrieb Rudolf Koenig:
> Ein "update chek" koennte alles durchfuehren, aber keine Dateien
> schreiben/umbenennen. Dann wuerde man sehen, wass passiert.
> Wer Details sehen moechte, der kann dann die SVN Logs anschauen.

Am Freitag, 25. Mai 2012, 12:56:49 schrieb Martin Fischer:
> was hälst du davon, wenn wir update noch die optionen oder attribute
> <stable> und <unstable> spendieren? dazu müsste dann auf fhem.de einmal
> die letzte stable version bereitstehen, also akutell 5.2 und der svn
> mirror.

Am Montag, 28. Mai 2012, 11:07:29 schrieb Rudolf Koenig:
> > Es gibt also demnaechst 4 Versionen:
> > - fhemupdate
> > - fhemupdate2
> > - fhemupdate3/stable
> > - fhemupdate3/svn
> Weiterhin werde ich CHANGED auch ins fhemupdate packen. Ich finde man sollte
> die Liste der geaenderten Dateien trotzdem anzeigen, fuer den Fall, dass
> CHANGED vergessen wurde.

Am Freitag, 25. Mai 2012, 22:29:19 schrieb Martin Fischer:
> wie soll sich updatefhem (den man dann im zuge der obigen struktur dann
> vielleicht auch gleich in update umbenennen könnte?) per default verhalten?
>
> ich wäre ja dafür, wenn ein scharfer durchlauf nur mit einem
> zusatzparameter möglich ist. das ist zwar am anfang gewöhnungsbedürftig,
> würde aber verhindern, das ein unbedarfter mal eben "updatefhem"
> ausprobiert und alles übergebügelt wird.

Am Freitag, 25. Mai 2012, 22:29:19 schrieb Martin Fischer:
> updatefhem <stable|svn>
> holt filetimes.txt aus <stable> oder <svn>, prüft ob sich was verändert hat:
> => nein, dann rückmeldung, das es nichts neues gibt.
> => ja, kurzer hinweis am anfang, das lediglich in der folgenden ausgabe ein
> auszug (ersten 50 zeilen?) aus dem changelog folgt und im anschluss eine
> liste der geänderten files sowie das über "updatefhem <stable|svn>
> <install>" die installation gestartet werden kann.
>
> updatefhem <stable|svn> <install>
> holt filetimes.txt aus <stable> oder <svn>, prüft ob sich was verändert hat:
> => nein, siehe oben
> => ja, files werden installiert, dabei erfolgt zum ende die ausgabe der
> neuen / verändertem files
>
> und zu guter letzt nur noch den housekeeping kram dann etwas vereinfacht
> über
>
> updatefhem <stable|svn> <housekeeping> [clean]
> also wird <install> durch <housekeeping> ersetzt, dann wird es auch gleich
> durchgeführt (weil man sich ja vorher über updatefhem <svn|stable>
> informieren kann) und verhält sich wie ein <install> nur halt mit dem
> aufräumen von pgm2. optional dann noch clean, wenn gleich "gesäubert"
> werden soll. backup dann komplett ausgelagert, wird aber automatisch bei
> <install|housekeeping> [clean] angestossen.
>
> demnach würde updatefhem wie folgt aussehen:
>
> updatefhem <stable|svn> [install|housekeeping [clean]]

Am Samstag, 26. Mai 2012, 10:50:11 schrieb Rudolf Koenig:
> Ich finde die "housekeeping" Option ueberfluessig (oder ich verstehe es
> nicht
> :), bzw. ich haette es lieber als default. Wenn man es nicht durchfuehrt,
> :dann
> werden wahrscheinlich entweder "nur" Leichen herumliegen, die verwirren, im
> schlimmsten Fall funktioniert was nicht, weil die notwendige Datei dazu an
> der falschen Stelle liegt. Ich kann mir im Momant nicht vorstellen, was
> dabei zusaetzlich zum alten Verfahren geloescht waere.

Am Freitag, 1. Juni 2012, 09:24:08 schrieb Rudolf Koenig:
> Koennen wir "install" rauslassen? Ich haette gerne ein updatefhem was lieber
> nicht perfekt, dafuer aber einfach zu verstehen ist, als andersherum.

Am Freitag, 1. Juni 2012, 09:15:49 schrieb Rudolf Koenig:
> Ich wuerde gerne "www/" im Pfad streichen. Widerstand?
>
> Und ich wuerde die SVN Struktur bzw. Inhalt angleichen.

[Rudolf Koenig]

> nach der untenstehenden auflistung der argumente, w�rde ich updatefhem wie
> folgt �ndern:
...

Ok.

> egal welches update aufgerufen wird: 'backup' wird angestossen.

Bitte nur dann, falls update was ergibt. Wird trotzdem zu (Platz-)Probleme
fuehren falls man nicht aufraeumt.


> man k�nnte filetimes.txt zu einer art "steuerdatei" ausweiten und eine spalte
> noch davor einf�gen (DEL f�r l�schen, MOV f�r umbenennen,--- keine
> sonderbehandlung):

Auch ok, automatisch wird UPD (statt ---) und DEL generiert fuer die "normalen"
Dateien, und MOV kommt aus einem separat eingecheckten Datei fuer die .gplots
usw.

Also etwa so:
UPD 2012-04-17_07:45:10 4362 FHEM/98_structure.pm
UPD 2012-05-21_07:45:09 13924 FHEM/98_update.pm
DEL FHEM/99_updatefhem.pm
MOV FHEM/*.gplot www/gplot

[Martin Fischer]

Am Samstag, 2. Juni 2012, 10:37:08 schrieb Rudolf Koenig:
> [...]

> > egal welches update aufgerufen wird: 'backup' wird angestossen.
>
> Bitte nur dann, falls update was ergibt. Wird trotzdem zu (Platz-)Probleme
> fuehren falls man nicht aufraeumt.

schon klar! soweit denke ich dann gerade auch noch ;-)

> > man könnte filetimes.txt zu einer art "steuerdatei" ausweiten und eine

> > spalte noch davor einfügen (DEL für löschen, MOV für umbenennen,--- keine

> > sonderbehandlung):
> Auch ok, automatisch wird UPD (statt ---) und DEL generiert fuer die
> "normalen" Dateien, und MOV kommt aus einem separat eingecheckten Datei
> fuer die .gplots usw.
>
> Also etwa so:
> UPD 2012-04-17_07:45:10 4362 FHEM/98_structure.pm
> UPD 2012-05-21_07:45:09 13924 FHEM/98_update.pm
> DEL FHEM/99_updatefhem.pm
> MOV FHEM/*.gplot www/gplot

es gibt ja verschiedene status:
- datei unverändert
- datei verändert
- datei neu
- datei zu entfernen
- datei zu verschieben

MOV, DEL und UPD beschreiben 3 der obigen status. wie sollen dann die
verbleibenen gekennzeichnet werden? also
- datei unverändert
- datei neu

neu kann ja gleichgesetzt werden mit UPD. was ist aber mit unverändert? daher
kam übrigens mein "---" ;-)

dann noch eine anmerkung:
ich weiss noch nicht ob ich probleme mit regexp bekomme, also dein beispiel
mit "MOV FHEM/*.gplot www/gplot". um sicher zu gehen, würde ich lieber _jede_
datei einzeln gelistet lassen. oder eine andere idee?

[Rudolf Koenig]

> neu kann ja gleichgesetzt werden mit UPD. was ist aber mit unver�ndert? daher
> kam �brigens mein "---" ;-)

Kann ich nachvollziehen. Ich wuerde trotzdem beim UPD bleiben, man weiss ja
schliesslich nie, wan der Benutzer zuletzt ein update gemacht hat.

> ich weiss noch nicht ob ich probleme mit regexp bekomme, also dein beispiel

> mit "MOV FHEM/*.gplot www/gplot". um sicher zu gehen, w�rde ich lieber _jede_
> datei einzeln gelistet lassen.

Das funktionert aber nicht fuer die vom Benutzer erstellten .gplots, deswegen
glob (oder von mir aus regexp).

[Martin Fischer]

Am Samstag, 2. Juni 2012, 15:57:51 schrieb Rudolf Koenig:
> > neu kann ja gleichgesetzt werden mit UPD. was ist aber mit unverändert?
> > daher kam übrigens mein "---" ;-)

>
> Kann ich nachvollziehen. Ich wuerde trotzdem beim UPD bleiben, man weiss ja
> schliesslich nie, wan der Benutzer zuletzt ein update gemacht hat.

ist ja kein problem. es gibt ja immer noch die filetime.

> > ich weiss noch nicht ob ich probleme mit regexp bekomme, also dein
> > beispiel

> > mit "MOV FHEM/*.gplot www/gplot". um sicher zu gehen, würde ich lieber

> > _jede_ datei einzeln gelistet lassen.
>
> Das funktionert aber nicht fuer die vom Benutzer erstellten .gplots,
> deswegen glob (oder von mir aus regexp).

ja, da sprechen wir von zwei ausgangspunkten. ich meine das MOV in der
steuerdatei filetimes.txt, das sich aus meiner sicht _ausschliesslich_ auf
fhem eigene dateien bezieht.

die von dir angesprochenen benutzerdateien, sehe ich im abschnitt
housekeeping.. auch wenn es ggf. nicht mehr so heissen wird, sondern per
default verschoben wird (wie von dir vorgeschlagen).

nachdem wir uns nun schon auf die funktion

'update <svn|stable> [<file>|changed|fhem|pgm2]'

vorerst geeinigt haben, muss das neue format von 'filetimes.txt' sowie die
künftige struktur stehen, damit wir die user nicht überstrapazieren mit
ständigen änderungen.

erst dann kann ich sinnvoll anfangen.

[Martin Fischer]

Am Freitag, 1. Juni 2012, 15:30:42 schrieb Martin Fischer:
> Am Montag, 28. Mai 2012, 11:07:29 schrieb Rudolf Koenig:
> > > Es gibt also demnaechst 4 Versionen:
> > > - fhemupdate
> > > - fhemupdate2
> > > - fhemupdate3/stable
> > > - fhemupdate3/svn
> >
> > Weiterhin werde ich CHANGED auch ins fhemupdate packen. Ich finde man
> > sollte die Liste der geaenderten Dateien trotzdem anzeigen, fuer den
> > Fall, dass CHANGED vergessen wurde.

hast du das CHANGED schon in die entsprechenden verzeichnisse kopiert? ich
wollte das gerade integrieren, sieht aber so aus, als wenn es noch nicht drin
ist.

[Rudolf Koenig]

> hast du das CHANGED schon in die entsprechenden verzeichnisse kopiert?

Nein, habs vergessen, aber gerade eben nachgeholt, und 3-mal hochgeladen:
fhemupdate, fhemupdate2, fhemupdate3/stable. fhemupdate3/svn ist ja symlink.

[Martin Fischer]

prima... habe gerade eben ein neues updatefhem eingecheckt..

es war durch die verzeichnis umstellung noch ein fehler im CULflash und dann
habe ich noch eine neues globales attribute <exclude_from_update> spendiert um
lokale dateien gegen überschreiben zu schützen.

ausserdem wird das CHANGED file jetzt bis zu der ersten auftretenden leerzeile
angezeigt, sowie die zu ändernden dateien, wenn man 'updatefhem changed'
aufruft.

habe viel getestet und bisher ist mir kein fehler aufgefallen.

[Martin Fischer]

Am Samstag, 2. Juni 2012, 20:30:28 schrieb Martin Fischer:
> [...]

> vorerst geeinigt haben, muss das neue format von 'filetimes.txt' sowie die
> künftige struktur stehen, damit wir die user nicht überstrapazieren mit
> ständigen änderungen.
>
> erst dann kann ich sinnvoll anfangen.

gibt es hier schon einen neuen stand? nur um missverständnisse auszuräumen:
ich gehe davon aus, das du rudi das format der filetimes.txt umstellst? gerne
in der übergangszeit auch unter einem neuen namen wie z.b. controls.txt oder
so, damit es nicht mit der aktuellen updatefhem kollidiert.

oder liege ich mit der annahme falsch, das du die datei anpasst? denn das muss
ja irgendwie mit deinem svn-mirror und hochladescript zusammenspielen. da
möchte ich nur ungern eingreifen.

[Rudolf Koenig]

> oder liege ich mit der annahme falsch, das du die datei anpasst?

Ja mache ich, Do oder Sa/So. Ich wollte noch abwarten, dass das Thema sich
beruhigt, und keine Aenderungen mehr eintreffen. Die Idee mit dem neuen
Dateinamen ist gut.

Noch zu bedenken ist, dass wenn jemand vom svn auf stable zurueckgeht, evtl.
"Leichen" von der SVN Version behaelt, bzw. automatisch verschobene Dateien
(.gplot/etc) per Hand zurueckschieben muss.

[Martin Fischer]

Am Dienstag, 5. Juni 2012, 14:59:57 schrieb Rudolf Koenig:
> > oder liege ich mit der annahme falsch, das du die datei anpasst?
>
> Ja mache ich, Do oder Sa/So. Ich wollte noch abwarten, dass das Thema sich
> beruhigt, und keine Aenderungen mehr eintreffen. Die Idee mit dem neuen
> Dateinamen ist gut.

alles klar. bis jetzt läuft es ja ganz gut. hast du eine statistik auf dem
server wieviel zugriff stattgefunden haben?

> Noch zu bedenken ist, dass wenn jemand vom svn auf stable zurueckgeht, evtl.
> "Leichen" von der SVN Version behaelt, bzw. automatisch verschobene Dateien
> (.gplot/etc) per Hand zurueckschieben muss.

tja, in der tat. die frage die ich mir stelle: wie erkenne ich stable oder svn
installiert ist? evtl. durchs auslesen der release von fhem.pl

allerdings bin ich im moment der meinung, dass dann der benutzer selber hand
anlegen muss. den aufwand das auch noch zu automatisieren und alle
eventualitäten zu berücksichtigen halte ich für zu hoch.

folgendes kommt mir da spontan als idee:
ausgangslage: svn installiert, benutzer will zurück auf stable:
updatefhem warnt das sicherheitshalber "backup" per hand aufzurufen ist (falls
er zwischenzeitlich mit <backup_before_update> gespielt hat und evtl. kein
aktuelles backup hat) und ggf. fhem nach dem downgrade von hand angepasst
werden muss.

der andere weg, also von svn nach einer höheren stable sollte ja normal
funktionieren oder übersehe ich da was?

[Rudolf Koenig]

> Ja mache ich, Do oder Sa/So. Ich wollte noch abwarten, dass das Thema sich
> beruhigt, und keine Aenderungen mehr eintreffen. Die Idee mit dem neuen
> Dateinamen ist gut.

Es gibt jetzt zusaetzlich auf fhem.de:
fhemupdate2/controls.txt
fhemupdate3/svn/controls.txt
fhemupdate3/stable/controls.txt

und im SVN ein contrib/fhemupdate.control, der an die generierte controls.txt
angehaengt wird.

Gruss,
Rudi

[Martin Fischer]

Am Donnerstag, 7. Juni 2012, 16:13:22 schrieb Rudolf Koenig:
> [...]

> Es gibt jetzt zusaetzlich auf fhem.de:
> fhemupdate2/controls.txt
> fhemupdate3/svn/controls.txt
> fhemupdate3/stable/controls.txt
>
> und im SVN ein contrib/fhemupdate.control, der an die generierte
> controls.txt angehaengt wird.

prima.. ich schau mir das am wochenende an.

[Martin Fischer]

erstens kommt es anders und zweitens als man denkt.. bin bisher noch nicht
dazu gekommen, da mir gerade andere sachen dazwischen hauen..

[Martin Fischer]

bin gerade dabei weiter an update / updatefhem zu arbeiten...

ich überlege gerade, mit welcher logik ich besser unterscheiden kann ab wann
das argument housekeeping _nicht_ mehr zur verfügung steht. bisher habe ich
das ja davon abhängig gemacht, ob $modpath/www exisitert oder nicht. das
scheint mir zu unsicher und unflexibel.

besser: $attr{global}{version} zu nutzen

aber aktuell steht bei einer svn version dort "global version =VERS= from
=DATE= ($cvsid)" welches du wahrscheinlich vor einem release durch die version
und datum ersetzt.

das nächste release wird ja wohl die 5.3 sein, also ist meine überlegung zur
zeit: beinhaltet $attr{global}{version} >= 5.3 dann steht das attribut
"housekeeping" _nicht_ mehr zur verfügung.

mein problem:
$attr{global}{version} aus dem SVN beinhaltet immer =VERS=. damit kann ich
natürlich nicht erkennen ob jemand schon eine version >= 5.3 einsetzt und
schon neue updates aus dem svn bezogen hat, oder ob es sich noch um eine
version < 5.3 mit svn updates handelt.

wie kommen wir da nun zukunftssicher aus dem dilemma?

eine idee:

=VERS= wird durch die aktuelle release plus SVN ersetzt, also 5.2-SVN und wenn
die version dann stable wird, ist =VERS= gleich 5.3

wenn ich dabei keinen gedankenfehler habe, sollte dadurch folgendes abzuleiten
sein:

version = "5.2": aktuelle stable
version = "=VERS=": aktuelle SVN version basierend auf 5.2

wenn du das obige noch _vor_ der 5.3 einbaust, dann
version = "5.2-SVN": aktuelle SVN version ab gewissem datum

wenn dann die neue release draussen ist, dann
version = "5.3": aktuelle stable, die dann auch schon durch das makefile die
neue struktur berücksichtigt und housekeeping somit überflüssig ist.
version = "5.3-SVN": updates aus SVN basierend auf 5.3

bleiben nun noch folgende fälle:
installiert ist 5.2 und der anwender hat bisher kein housekeeping durchgeführt
und ruft updatefhem bisher mit "preserve" auf. ab 5.3 sollen aber _alle_ auf
die neue struktur.

installiert ist eine version < 5.2 (updatefhem kam glaub ich mit 5.0) und der
anwender will auf 5.3.


andere idee (meine derzeit präverierte, wobei ich das mit dem =VERS= :

im moment weiche ich davon ab 99_updatefhem.pm zu überarbeiten, sondern fange
auf der "grünen wiese" mit 99_update.pm neu an. die idee: 99_update.pm wird
bei einem neuen update verteilt und löscht 99_updatefhem.pm die dann auch
nicht mehr bei weiteren updates vom server geholt wird. also wenn einmal
99_update.pm drauf ist, dann gibt es kein 99_updatefhem.pm mehr.

sobald 99_update.pm verteilt wird, wird automatisch ein "updatefhem
housekeeping clean yes" durchgeführt und anschliessend wie beschrieben, die
99_updatefhem.pm gelöscht. problem dabei: was ist, wenn der anwender das
backup ausgeschaltet hat, bzw. es nicht funktioniert (z.b. unter windows)?

also irgendwie müsste ich zuverlässig erkennen können ob ein housekeeping
schon durchgeführt wurde oder das durch eine offline-installation schon die
neue struktur besteht.

ideen?

ich mache jetzt erstmal an 99_update.pm ohne rücksicht auf _housekeeping_
weiter.

hier ein paar beispiele wie "99_update.pm" arbeiten wird:

fhem> update ?
Usage: update [svn|stable] [<file>|changed|fhem|full|housekeeping|pgm2]

fhem> update
trunk:'STABLE' srcdir:'/fhemupdate3/stable' update:'FULL'

FULL bedeutet: update von FHEM _und_ PGM2 und ist defaultwert. wahlweise kann
aber auch _nur_ fhem oder pgm2 aktualisiert werden.

über ein globales attribut kann der trunk von default "STABLE" auf "SVN"
geändert werden:

fhem> update
trunk:'SVN' srcdir:'/fhemupdate3/svn' update:'FULL'

durch angabe von SVN oder STABLE beim aufruf, kann man aber den trunk
erwzingen: als beispiel ist default trunk auf STABLE:

fhem> update svn
trunk:'SVN' srcdir:'/fhemupdate3/svn' update:'FULL'

über das argument kann auch beeinflusst werden, was geholt werden soll:

fhem> update pgm2
trunk:'STABLE' srcdir:'/fhemupdate3/stable' update:'pgm2'

fhem> update svn pgm2
trunk:'SVN' srcdir:'/fhemupdate3/svn' update:'pgm2'

fhem> update fhem
trunk:'STABLE' srcdir:'/fhemupdate3/stable' update:'fhem'

fhem> update 01_foobar.pm
trunk:'STABLE' srcdir:'/fhemupdate3/stable' update:'01_foobar.pm'

fhem> update svn 01_foobar.pm
trunk:'SVN' srcdir:'/fhemupdate3/svn' update:'01_foobar.pm'

fhem> update changed
trunk:'STABLE' srcdir:'/fhemupdate3/stable' update:'changed'

fhem> update svn changed
trunk:'SVN' srcdir:'/fhemupdate3/svn' update:'changed'

[Rudolf Koenig]

> =VERS= wird durch die aktuelle release plus SVN ersetzt, also 5.2-SVN und wenn
> die version dann stable wird, ist =VERS= gleich 5.3

Ich verstehe nicht genau, was Dir fehlt:

attr global version ist eins vonn beiden
- 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $)
- 5.2 from 2011-12-31 ($Id: fhem.pl 1159 2011-12-31 13:31:58Z rudolfkoenig $)

In beiden Versionen sind sowohl Version als auch Datum als Grundlage fuer die
Entscheidung verfuegbar. Wer fhem.pl aus SVN holt, der ist selbst schuld, dem
darf main ein update verweigern.

Aber eigentlich sollte fuer die Entscheidung eher ein Versionsnummer in
updatefhem dienen. Das Problem liegt eher anders: nur ein aktueller updatefhem
kann die korrekte Struktur herstellen, ein updatefhem aus 5.2 wird die Daten
nicht wie gewuenscht herunterladen, man muss update also zwangsweise zweimal
durchfuehren.

Z.Zt waere auch update stable ein Problem, weil fhem "attr global port xxx" aus
fhem.cfg loescht, und mit "define telnetPort telnet xxx" ersetzt. Ein altes
fhem kann aber damit nix anfangen, "update stable" muesste also das alte konfig
herstellen, und Aenderungen zwischen den Updates verlieren. update stable darf
also nur auf einem neueren Version, nicht aber auf einem vorherigen updaten.

Je mehr ich darueber nachdenke: ich moechte nur zwei Zustaende haben: mit oder
ohne updatefhem, und supporten will ich nur letzteres. Der Rest ist mir zu
viel wg. Test bzw. Support. Auch jetzt macht Vielfalt Support kompliziert, das
reicht mir schon.



> im moment weiche ich davon ab 99_updatefhem.pm zu �berarbeiten, sondern fange
> auf der "gr�nen wiese" mit 99_update.pm neu an. die idee: 99_update.pm wird
> bei einem neuen update verteilt und l�scht 99_updatefhem.pm die dann auch

> nicht mehr bei weiteren updates vom server geholt wird. also wenn einmal
> 99_update.pm drauf ist, dann gibt es kein 99_updatefhem.pm mehr.

Du kannst gerne neu anfangen, den Vorteil des Umbenennens sehe ich aber im
Moment noch nicht.

[Martin Fischer]

Am Sonntag, 24. Juni 2012, 08:55:57 schrieb Rudolf Koenig:
>[...]

> attr global version ist eins vonn beiden
> - 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z
> rudolfkoenig $) - 5.2 from 2011-12-31 ($Id: fhem.pl 1159 2011-12-31
> 13:31:58Z rudolfkoenig $)
>
> In beiden Versionen sind sowohl Version als auch Datum als Grundlage fuer
> die Entscheidung verfuegbar. Wer fhem.pl aus SVN holt, der ist selbst
> schuld, dem darf main ein update verweigern.

ok.. wenn man jedoch an fhem entwickelt und sich dabei auf eine svn version
beruft, dann steht dort eben =VERS= und =DATE=. dass das dann später von dir
für updatefhem gesetzt wird, habe ich nicht gesehen. damit ist das nun klar
(oder zitat: "ich bin selber schuld").

> [...]

> update stable darf also nur auf einem neueren Version, nicht aber auf einem
> vorherigen updaten.

das sollte so sein.

> Je mehr ich darueber nachdenke: ich moechte nur zwei Zustaende haben: mit
> oder ohne updatefhem, und supporten will ich nur letzteres. Der Rest ist
> mir zu viel wg. Test bzw. Support. Auch jetzt macht Vielfalt Support
> kompliziert, das reicht mir schon.

dazu gilt es die software so zu gestalten, das sie möglichst wenig support
benötigt aber dennoch vielfalt bietet. das ist der trick dabei ;-)

deine aussage: "ich moechte nur zwei Zustaende haben: mit oder ohne
updatefhem, und supporten will ich nur letzteres." kann ich nun wirklich nicht
wechseln. wenn du support für fhem nur _ohne_ updatefhem machen möchtest,
warum gibt es dann den befehl "updatefhem"?

_keiner_ ist vepflichtet zu supporten.

>[...]

> Du kannst gerne neu anfangen, den Vorteil des Umbenennens sehe ich aber im
> Moment noch nicht.

ganz einfach: es geht um das wording sowie um vorausschauende funktionen.

wenn sich ein anwender bei der installation bewusst dafür entschieden hat
_nur_ FHEM zu installieren (make install), dann suggeriert der befehl
"updatefhem" allein vom namen her, das halt auch _nur_ FHEM aktualisiert wird.
tatsächlich wird aber FHEM _und_ eine webgui namens PGM2 aktualisiert.

um nun zu vermeiden, das es auch ein "updatepgm2" gibt, erfolgt die
umbenennung in "update" und wahlweise kann dann entschieden werden, _was_ man
updaten will: FULL (FHEM + PGM2), nur FHEM oder nur PGM2.

des weiteren könnte man das ggf. um andere parameter erweitern: z.b. "update
NEUEGUI", wobei die "NEUEGUI" dann nicht von fhem.de gezogen wird, sondern wo
anders liegt. oder ein "update icons", welches dann nur die "shared icons"
aktualisiert, etc.

wie gesagt: es geht mehr ums wording und eine klarere abgrenzung _was_
eigentlich aktualisiert werden soll.

[Rudolf Koenig]

> wie gesagt: es geht mehr ums wording und eine klarere abgrenzung _was_
> eigentlich aktualisiert werden soll.

Ok, akzeptiert.

[Martin Fischer]

Am Sonntag, 24. Juni 2012, 08:55:57 schrieb Rudolf Koenig:

> Z.Zt waere auch update stable ein Problem, weil fhem "attr global port xxx"
> aus fhem.cfg loescht, und mit "define telnetPort telnet xxx" ersetzt. Ein
> altes fhem kann aber damit nix anfangen, "update stable" muesste also das
> alte konfig herstellen, und Aenderungen zwischen den Updates
> verlieren. update stable darf also nur auf einem neueren Version, nicht
> aber auf einem vorherigen updaten.

fhem> update
The installed version (5.2+SVN) is newer than the remote version (5.2).
A downgrade is not allowed! Your updatepath is 'STABLE'. You can set the
default updatepath via the global attribute 'update_from'.
You can force the downgrade with the argument 'force' (e.g. 'update force') at
your own risk. In case of problems, there is no support from the developers!

zufrieden? ;-)

auf die version von fhem bezogen wird abgefangen (hier mit beispielwerten,
geht aber mit allen künfigen / bestehenden versionen solange die notation von
version weiterhin major.minor bleibt):
- remote: 5.2, local: 5.3
- remote: 5.2, local: 5.2+SVN

beeinflusst werden kann das mittels 'force'. dann aber selber schuld, wenn was
nicht läuft.

bleibt die frage auf welchen wert ich das globale attribute 'update_from'
voreinstellen soll: STABLE oder SVN.

das mit STABLE und SVN bietet übrigens folgenden vorteil:
während ein update aus SVN auch fehlerhafte (test)module ausliefert, würde ein
update aus STABLE nur getestete, fehlerfreie module ausliefern.

d.h.: auch benutzer, die "auf nummer sicher" gehen und _nur_ stabile module
einsetzen wollen, könnten dann auf STABLE bleiben, würden aber davon
profitieren, wenn wir mal was von SVN nach STABLE schieben. dies können z.b.
nur bugfixes sein.

neue module gäbe es auf STABLE nur dann, wenn eine neue STABLE eine neue
version released wurde oder aber der benutzer gezielt mit "update svn
<file.pm>" diese aus dem svn zieht.

demnach könnte es künftig so aussehen:

fhem-5.3.tar.gz == STABLE release
fhem-nightly.tar.gz == SVN release

fhemupdate3/stable == 5.3 sowie wichtige bugfixes.
fhemupdate3/svn == 5.3 plus alle neuerungen.

d.h. dann das fhem-5.3.tar.gz != fhemupdate3/stable ist, was ich aber nicht
schlimm finde. dahinter steht ja das gleiche prinzip wie bei jeder anderen
distribution: man installiert z.b. kubuntu 12.04 und holt sich dann update.
das kubuntu bleibt dann aber immer noch version 12.04.

SVN wird dann irgendwann zu 5.4 und bezieht dann wieder bugfixes aus
fhemupdate3/stable und wer "mutig" ist, kann dann komplett aus fhemupdate3/svn
updaten oder nur vereinzelte dateien daraus ziehen.

also _ICH_ finde die funktionalität vom neuen update gut durchdacht.

andere meinungen dazu? oder habe ich irgendein fallstrick vergessen?

martin

[Dr. Boris Neubert]

Hallo,

Am 24.06.2012 14:24, schrieb Martin Fischer:
> fhem> update

Zusammenfassung:

Ich bekomme per update zwei Zweige
STABLE= 5.2 Release+Bugfixes
SVN= 5.2 Release+laufende Entwicklung

Ich bin mit meiner Installation entweder auf dem einen oder auf dem
anderen Zweig.

Ein Wechsel von STABLE nach SVN ist ein Upgrade und geht immer, ein
Wechsel von SVN nach STABLE ist ein Downgrade, von dem abgeraten wird.

Updates auf dem STABLE-Zweig bringen mir gut getestete stabile
Versionen, 5.2, 5.3, 5.4, ... und ab und zu Bugfixes.

Updates auf dem SVN-Zweig sind für die Anwender, die es lieben,
frühzeitig neue Features zu benutzen und Bugs risikieren.

Man kann auch nur einzelne Dateien aus dem SVN ziehen, wenn man im
STABLE-Zweig ist.

Frage dazu:

Aufgrund von Abhängigkeiten ist man im letztgenannten Fall aber schon
mal ganz schnell dabei, ein neues fhem.pl zu brauchen. Ist man danach
automatisch auf dem SVN-Zweig?



SVN: wir haben derzeit
- trunk: da ist drin, was dem o.g. SVN-Zweig entspricht
- branches/testing: da ist drin, was wir noch nicht mal den Usern auf
dem SVN-Zweig zumuten

Wir brauchen m.E. noch
- branches/stable

Ich nehme mal an, daß wir einen älteren STABLE-Zweig (5.2) nicht warten,
wenn ein neuerer STABLE-Zweig (5.3) herausgekommen ist. Sonst bräuchten
wir unter branches/stable noch die Versionen.

Viele Grüße
Boris

[Martin Fischer]

hallo boris,

Am Sonntag, 24. Juni 2012, 14:47:35 schrieb Dr. Boris Neubert:
> [...]

> Zusammenfassung:
>
> Ich bekomme per update zwei Zweige
> STABLE= 5.2 Release+Bugfixes
> SVN= 5.2 Release+laufende Entwicklung
>
> Ich bin mit meiner Installation entweder auf dem einen oder auf dem
> anderen Zweig.

du hast das super zusammengefasst. es trifft genau die aktuelle arbeitsweise
von update und das was ich als sinnvoll erachte.

> [...]

> Man kann auch nur einzelne Dateien aus dem SVN ziehen, wenn man im
> STABLE-Zweig ist.
>
> Frage dazu:
>
> Aufgrund von Abhängigkeiten ist man im letztgenannten Fall aber schon
> mal ganz schnell dabei, ein neues fhem.pl zu brauchen. Ist man danach
> automatisch auf dem SVN-Zweig?

das ist in der tat ein problem, da sich die abfrage der version an fhem.pl
ausrichtet und das "release" (also fhem-5.2.tar.gz z.b.) an der version von
fhem.pl orientiert. aus meiner sicht handelt es sich bei fhem-5.2.tar.gz aber
um eine suite, die durch aus ein fhem.pl in der version 7.2 enthalten könnte.

idealerweise ware sowas wie lsb-release bei z.b. (k)ubunutu:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04 LTS"

auf fhem übertragen könnte das z.b. in eine release.pm und folgenden inhalt
ausweisen:
DISTRIB_ID=Fhem
DISTRIB_RELEASE=5.2
DISTRIB_DESCRIPTION="Fhem 5.2 STABLE"

oder

DISTRIB_ID=Fhem
DISTRIB_RELEASE=5.2+SVN
DISTRIB_DESCRIPTION="Fhem 5.2 SVN"

das würde es klarer machen und ein update von fhem.pl aus fhemupdate3/svn wäre
möglich. fhem.pl selber beinhaltet nicht mehr hardcoded die version, sondern
bezieht diese auch aus release.pm. und anhand der cvs-id von fhem.pl kann man
im supportfall ja auch den benutzer fragen, da diese ja auch bei list global
angezeigt wird.

alternativ könnte man ja auch ein "support" befehl einbauen, der dann
wahlweise die cvsids _aller_ module inkl. fhem.pl anzeigt oder nur gezielt von
einem modul / fhem.pl. so nach dem motto:
fhem> version fhem.pl
fhem.pl 1204 2012-01-22 12:21:05Z rudolfkoenig

fhem> version
fhem.pl 1204 2012-01-22 12:21:05Z rudolfkoenig
00_CM11.pm 1098 2011-11-12 07:51:08Z rudolfkoenig
00_CUL.pm 1354 2012-03-16 06:50:47Z rudolfkoenig
00_FHZ.pm 1148 2011-12-28 19:21:19Z rudolfkoenig
...

wenn das auf eure zustimmung stösst, dann würde ich die änderung mit der
release.pm und dem "version" befehl umsetzen.

@rudi: meinung dazu?

> SVN: wir haben derzeit
> - trunk: da ist drin, was dem o.g. SVN-Zweig entspricht

richtig..
update erfolgt aus "fhemupdate3/svn"

> - branches/testing: da ist drin, was wir noch nicht mal den Usern auf
> dem SVN-Zweig zumuten

auch richtig.. soll das aber auch bestandteil von "update" werden?

> Wir brauchen m.E. noch
> - branches/stable

stimme ich zu, aber das entspricht meinem verständnis nach aktuell dem STABLE
update erfolgt aus "fhemupdate3/stable"

> Ich nehme mal an, daß wir einen älteren STABLE-Zweig (5.2) nicht warten,
> wenn ein neuerer STABLE-Zweig (5.3) herausgekommen ist. Sonst bräuchten
> wir unter branches/stable noch die Versionen.

ich wäre auch dafür, _keine_ älteren zweige zu pflegen. demnach benötigt man
keine weitere versionen unterhalb von branches/stable.

noch ein kurzes wort zu den bezeichnungen trunk, branches, svn, stable.

mir fehlt irgendwie ein verständlicher "oberbegriff" für den "updatezweig" als
verständlicher name für eine globale variable. derzeit habe ich die variable
"update_from" genannt und die versteht SVN oder STABLE. per default (wenn
nicht gesetzt) steht sie auf STABLE.

innerhalb von update.pm verwende ich die variable $TRUNK die je nach angabe
entweder "STABLE" oder "SVN" enthält. also $TRUNK entspricht der vorgabe aus
der globalen variablen "update_from" wird aber geändert wenn der benutzer bei
"update" etwas angibt. beispiel:

$attr{global}{update_from} = STABLE
fhem> update
$TRUNK = STABLE
fhem> update svn
$TRUNK = SVN
fhem> update stable
$TRUNK = STABLE

$attr{global}{update_from} bleibt dabei unangetastet, es sei denn es wird
explitit neu gesetzt. dann verhält sich update wie folgt:

fhem> attr global update_from SVN
fhem> update
$TRUNK = SVN
fhem> update stable
$TRUNK = STABLE
fhem> update svn
$TRUNK = SVN

die beispiele gehen von einen FULL-update aus. das geht natürlich auch für
einzelne:
update [svn|stable] [<file>|changed|fhem|full|pgm2] [force]

nun die gretchenfrage:
wie soll das globale attribut ( zur zeit "update_from" ) im sinne von trunk,
branch, svn, stable vereinfacht heissen?

wie ist die meinung zur _internen_ variable $TRUNK? gibt es da nicht auch
einen sinnvolleren namen? $TRUNK und $attr{global}{update_from} sind
inhaltlich gleichbedeutend aber die globale variable sollte für anwender
_verständlicher_ sein.

denkbar wäre auch das $attr{global}{update_from} zum besseren verständnis nur
STABLE oder EXPERIMENTAL (anstatt von SVN) angeben kann. nicht jeder weiss was
SVN bedeutet.

wenn wir uns für einen einheitliche notation geeinigt haben, sollten darüber
hinaus (rudi wird mich nun erschlagen wollen ;-) ) die pfade auf fhem.de
angepasst werden.

ich haue jetzt weiter in die tasten.. alles was heute noch "entschieden" wird,
kann ich vielleicht schon berücksichten!

gruss martin

[Rudolf Koenig]

> andere meinungen dazu? oder habe ich irgendein fallstrick vergessen?

Also in der Theorie ist das einwandfrei, ich habe nur nicht vor irgendetwas in
STABLE zu fixen. Aber vielleicht will das jemand, insofern sage ich nichts
dagegen. Fuer diesen Feature muss auch noch fhemupdate angepasst werden, aber
ich warte diesmal solange, bis update fertig ist :)

[Rudolf Koenig]

> @rudi: meinung dazu?

Hab nichts dagegen, aber ich brauche es nicht: ich will nur SVN fixen, alles
andere ist mir zu bunt. Deswegen bitte von mir auch keine Entscheidungen
erwarten.


> wenn wir uns f�r einen einheitliche notation geeinigt haben, sollten dar�ber

> hinaus (rudi wird mich nun erschlagen wollen ;-) ) die pfade auf fhem.de
> angepasst werden.

Ich erschlage keinen, sondern warte diesmal etwas laenger mit irgendwelcher
Implementierungen :)

[Dr. Boris Neubert]

Hallo,

Am 24.06.2012 15:53, schrieb Martin Fischer:
> auf fhem übertragen könnte das z.b. in eine release.pm und folgenden inhalt

das finde ich gut!

> wenn das auf eure zustimmung stösst, dann würde ich die änderung mit der
> release.pm und dem "version" befehl umsetzen.

OK!

> ich wäre auch dafür, _keine_ älteren zweige zu pflegen. demnach benötigt man
> keine weitere versionen unterhalb von branches/stable.

OK.

> nun die gretchenfrage:
> wie soll das globale attribut ( zur zeit "update_from" ) im sinne von trunk,
> branch, svn, stable vereinfacht heissen?

Branch?

> denkbar wäre auch das $attr{global}{update_from} zum besseren verständnis nur
> STABLE oder EXPERIMENTAL (anstatt von SVN) angeben kann. nicht jeder weiss was
> SVN bedeutet.

STABLE, EXPERIMENTAL, UNSTABLE (für testing)?

Grüße
Boris

[Martin Fischer]

danke boris für die rückmeldung..

Am Sonntag, 24. Juni 2012, 17:47:12 schrieb Dr. Boris Neubert:
> [...]

> > denkbar wäre auch das $attr{global}{update_from} zum besseren verständnis
> > nur STABLE oder EXPERIMENTAL (anstatt von SVN) angeben kann. nicht jeder
> > weiss was SVN bedeutet.
>
> STABLE, EXPERIMENTAL, UNSTABLE (für testing)?

wenn wir UNSTABLE in update aufnehmen, dann müsste rudi auch täglich
branches/testing spiegeln. richtig?

ausserdem würde ich es dann auch TESTING nennen, da ja durchaus auch mal was
im EXPERIMENTAL unstable sein könnte ;-)

um dann die updatestreams analog zu dem global attribute "update_from_branch"
(den ich in "updatebranch" umbenennen werde) zu halten, würde ich vorschlagen,
das die verzeichnisse auf fhem.de dann wie folgt heissen:

STABLE = fhem.de/fhemupdate/stable
EXPERIMENTAL = fhem.de/fhemupdate/experimental
TESTING = fhem.de/fhemupdate/testing

alternativ (dann aber nicht ganz analog zu "updatebranch"):
STABLE = fhem.de/fhemupdate/stable
EXPERIMENTAL = fhem.de/fhemupdate/svn
TESTING = fhem.de/fhemupdate/testing

[Martin Fischer]

Am Sonntag, 24. Juni 2012, 17:35:15 schrieb Rudolf Koenig:
> [...]

> Hab nichts dagegen, aber ich brauche es nicht: ich will nur SVN fixen, alles
> andere ist mir zu bunt. Deswegen bitte von mir auch keine Entscheidungen
> erwarten.

schade.. aber das kommt bestimmt noch ;-)

[Dr. Boris Neubert]

Hallo,

Am 24.06.2012 19:00, schrieb Martin Fischer:
>
> STABLE = fhem.de/fhemupdate/stable
> EXPERIMENTAL = fhem.de/fhemupdate/experimental
> TESTING = fhem.de/fhemupdate/testing
>
> alternativ (dann aber nicht ganz analog zu "updatebranch"):
> STABLE = fhem.de/fhemupdate/stable
> EXPERIMENTAL = fhem.de/fhemupdate/svn
> TESTING = fhem.de/fhemupdate/testing

STABLE, EXPERIMENTAL, TESTING ist für mich OK, bei den Verzeichnissen
habe ich kein Stakes drin -> Rudi?

TESTING brauchen wir, damit noch ein paar Anwender meinen Umbau testen.
Wir werden sie mit dem Versprechen der tollen Icons für das
Weather-Device in die Update-Falle locken ]:-)

B.

[Martin Fischer]

Am Freitag, 29. Juni 2012, 20:31:02 schrieb Dr. Boris Neubert:
> [...]

> TESTING brauchen wir, damit noch ein paar Anwender meinen Umbau testen.
> Wir werden sie mit dem Versprechen der tollen Icons für das
> Weather-Device in die Update-Falle locken ]:-)

na dann musst du rudi aber davon überzeugen, das er auch noch test spiegelt
:-) _ich_ mach das nicht _auch_ noch.. nerv ihn die tage genug :-)

ne, spass beseite:

für dich boris, mal die info, das ich so im 2-3 tages turnus fleissig an
update.pm schreibe. bin auch schon gut vorangekommen. sollte also nicht mehr
allzu lange dauern.

gruss martin

[Rudolf Koenig]

> STABLE, EXPERIMENTAL, TESTING ist f�r mich OK, bei den Verzeichnissen

> habe ich kein Stakes drin -> Rudi?

Was genau ist der Unterschied zw. EXPERIMENTAL und TESTING?
Wenn wir jetzt schon Namen finden, dann sollte es eindeutiger sein.

Vorschlag/Idee: Wie waere es damit fhemupdate und fhem.de komplett umzugehen?
Der holt doch nur die Daten aus SVN, und laedt diese auf fhem.de hoch. Das geht
doch auch direkt:
http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/fhem.pl
http://fhem.svn.sourceforge.net/viewvc/fhem/tags/FHEM_5_2/fhem/fhem.pl


Der Benutzer spezifiziert
Repo: http://fhem.svn.sourceforge.net/viewvc/fhem
Zweig: trunk oder stable/FHEM_5_2 oder calendar_experiment

und kann damit beliebig updaten. Alternativ Repos sind auch trivial.

Was noch fehlt ist filetimes.txt/control.txt, den koennte weiterhin fhemupdate
erstellen, oder wir finden einen Weg das auch zu umgehen.

[Martin Fischer]

Am Samstag, 30. Juni 2012, 09:25:30 schrieb Rudolf Koenig:
> > STABLE, EXPERIMENTAL, TESTING ist für mich OK, bei den Verzeichnissen

> > habe ich kein Stakes drin -> Rudi?
>
> Was genau ist der Unterschied zw. EXPERIMENTAL und TESTING?
> Wenn wir jetzt schon Namen finden, dann sollte es eindeutiger sein.

boris hat das vorab geschrieben:
experimental = svn version zitat rudi: "wer aus dem svn updated muss damit
rechnen, das auch mal was _nicht_ auf anhieb funktioniert.". es ist halt
experimentel.

testing = nicht ganz zitat boris (aber so ähnlich): "entwicklungsstände, die
wir _nicht_ auf user loslassen wollen, sondern zwischen uns entwicklern zum
austausch _früher_ entwicklungsstände."

> Vorschlag/Idee: Wie waere es damit fhemupdate und fhem.de komplett
> umzugehen? Der holt doch nur die Daten aus SVN, und laedt diese auf fhem.de
> hoch. Das geht doch auch direkt:

> [...]

nichts gegen den vorschlag.. allerdings finde ich den zeitpunkt doch etwas
ungünstig. ich bin mit update.pm quasi auf der zielgerade und könnte dann
wieder den ganzen krams umbauen. not nice!

eigentlich wollte ich dieses wochenende update.pm weitestgehends
fertigstellen.

> Was noch fehlt ist filetimes.txt/control.txt, den koennte weiterhin
> fhemupdate erstellen, oder wir finden einen Weg das auch zu umgehen.

etwas background für boris, da ich das mit rudi schon direkter mail besprochen
hatte:

bis 5.2 benötigte man die filetimes.txt. ab 5.3 sollte es die controls.txt
werden. nach einiger überlegung und während des fortschritts von update.pm
habe ich festgestellt, das ich einen _eindeutige_ abgrenzung von fhem und pgm2
updates benötige.

der benutzer soll selber entscheiden, ober er _nur_ fhem oder _nur_ pgm2 oder
_alles_ (fhem + pgm2) updaten will. hintergrund: wenn der benutzer während der
erstinstallation _bewusst_ "make install" und _nicht_ "make install-pgm2"
aufruft, dann hat er sicherlich seine gründe und will nicht ein pgm2 während
eines update _untergeschoben_ bekommen. dieses verhalten hat / hatte
updatefhem.pm.

in update.pm soll diese abgrenzung nun laut meinem vorschlag wie folgt
vorgenommen werden:
die aktuell verwendete controls.txt soll abgelöst werden durch:
controls_fhem.txt
controls_pgm2.txt

in controls_fhem.txt stehen _alle_ dateien, für den _reinen_ betrieb _ohne_
webinterface (ala make install).
in controls_pgm2.txt stehen _zusätzliche_ dateien, die benötigt werden um pgm2
zu installieren / "upzudaten".

dabei können (und müssen evtl. sogar) dateien _doppelt_ auftauchen, wobei sie
aber faktisch auf die gleiche datei zeigen. beispiel:

in controls_fhem.txt steht fhem.pl und auch in controls_pgm2.txt. ruft also
der benutzer "update pgm2" auf (er will also _nur_ pgm2 updaten), dann wird
fhem.pl ebenfalls aktualisiert, sofern es neuer ist.

ruft der benutzer "update fhem" (= standardeinstellung, es reicht auch ein
"update") auf, dann wird _nur_ dir controls_fhem.txt verarbeitet.

vorteil: wenn wir irgendwann weitere "updatepakete", wie z.b. "update icons",
"update plots", "update gui7", "update docs" anbieten _wollten_ dann würden
einfach weitere controls_icons.txt, controls_plots.txt, etc. benötigt.

ausserdem könnte man ja sogar eine controls_test.txt einbinden, die dann
dateien aus einem anderen zweig einbindet.

diesem vorschlag stand rudis vorschlag dagegen, es anhand der verzeichnisse
festzumachen:
update fhem macht nur FHEM/*
update www macht nur www/*
update www/pgm2 macht nur www/pgm2/*

haken an dieser idee laut rudi: fhem.pl passt da nirgends rein. ich sehe da
noch weitere nachteile.

bei meinem vorschlag hat rudi bedenken, das er fhemupdate zu häufig ändern
müsste, was ich jedoch nicht so sehe. ich denke, das wenn wir uns erstmal auf
_pakete_ festgelegt haben, fhemupdate relativ stabil sein wird. halt in der
übergangsphase evtl. die eine oder andere _ergänzung_ von nöten.

damit endete die diskussion zwischen rudi und mir am 28.06. erstmal mit zitat
rudi "bisher unentschieden".

allerdings ist dies nun für mich zum "showstopper" geworden. ohne eine
sinnvolle abgrenzung von updatepaketen ala fhem, pgm2 und full komme ich eben
nicht weiter, so wie ich mir das eigentlich vorgenommen habe.

ich habe kein problem damit, wenn wir die datein direkt von sourceforge ziehen
aber ich benötige mit heutigem stand die controls_nnn.txt files, da ja dort
auch "steuerungsbefehle" inkludiert sind. wir hatten ja seinerzeit das
problem: wie benennen wir eine datei um, bzw. wie löschen wir alte dateien.
wie will man das dann ohne eine controls_nnn.txt umsetzen? einzige idee die
mir spontan einfällt, die neue datei release.pm dazu nutzen. das würde
bedeuten, das jeder der irgendwann im trunk oder stable was ändert auch die
release.pm anpassen _muss_ damit diese von update.pm als steuerdatei genutzt
werden kann. fragt sich nur, _was_ dann dort für informationen aufgenommen
werden die dazu ausreichen festzustellen wo der unterschied zwischen der
lokalen und der repository version der datein ist.

ich stimme ja immer noch für _meine_ idee :-) und bin auf boris' meinung
gespannt.

fakt ist jedoch: ich finde den zeitpnkt der diskussion, wie schon geschrieben,
jetzt quasi auf der zielgeraden nicht motivierend. mich bremst das nun aus und
ich habe auch wirklich keinen nerv den ganzen code von update.pm wieder
wegzuschmeissen.

als noch zeit war, da war das interesse eher gering sich an der diskussion
über den funktionsumfang und die arbeitsweise von update.pm zu beteiligen.
wenn ich jetzt wieder alles umstellen würde, dann würde uns das um mindestens
3-4 wochen zurückschmeissen.

martin

[Rudolf Koenig]

> ruft der benutzer "update fhem" (= standardeinstellung, es reicht auch ein
> "update") auf, dann wird _nur_ dir controls_fhem.txt verarbeitet.

Das sehe ich aus mehreren Gruenden probematisch:
- den meisten ist es nicht bewusst, dass FHEMWEB auch noch pgm2 heisst, und kein
integraler Teil von fhem ist.
- wer pgm2 installiert hat (default in den FB images und im .deb Paket, also
fuer die meisten), und ein "update fhem" durchfuert, dem kann passieren, dass
FHEMWEB danach nicht mehr geladen wird. Bei einem typischen Anfaenger mit
einem FB und Null UNIX Kenntnissen waer das ein K.O.
update ohne Argument muss fhem.pl und alle aktuell installierten Module
updaten, der Benutzer darf das nicht beeinflussen.

update ist fuer Leute ohne Ahnung, die mit Ahnung koennen es ja auch anders.
Je mehr Diskussionen/Probleme ich hier sehe, desto eher bin ich davon
ueberzeugt, dass ein update ohne Optionen vollkommen reichen wuerde.


> allerdings ist dies nun f�r mich zum "showstopper" geworden. ohne eine

> sinnvolle abgrenzung von updatepaketen ala fhem, pgm2 und full komme ich eben
> nicht weiter, so wie ich mir das eigentlich vorgenommen habe.

Das stoert mich wiederum, weil fhem z.Zt wegen updatefhem bzw. Verzeichnisumbau
in einem unstabilen Zustand ist, wenigstens wird das so wahrgenommen. Siehe
Ulis Post heute, und er ist kein Anfaenger. Deswegen moechte ich das Kapitel
moeglichst schnell abschliessen.


> ich stimme ja immer noch f�r _meine_ idee :-) und bin auf boris' meinung
> gespannt.

Ok, einverstanden, werde heute noch controls_fhem.txt und controls_pgm2.txt
zur Verfuegung stellen. Aber mein Punkt von oben sollte bitte beachtet werden.

[Rudolf Koenig]

> Ok, einverstanden, werde heute noch controls_fhem.txt und controls_pgm2.txt
> zur Verfuegung stellen. Aber mein Punkt von oben sollte bitte beachtet werden.

Es steht zu Verfuegung:
http://fhem.de/fhemupdate2/controls_fhem.txt
http://fhem.de/fhemupdate2/controls_pgm2.txt

Zum manuelles beeinflussen:
contrib/fhemupdate.control.fhem
contrib/fhemupdate.control.pgm2

[Dr. Boris Neubert]

Am 30.06.2012 17:26, schrieb Martin Fischer:
> der benutzer soll selber entscheiden, ober er _nur_ fhem oder _nur_ pgm2 oder
> _alles_ (fhem + pgm2) updaten will. hintergrund: wenn der benutzer während der

> ich stimme ja immer noch für _meine_ idee :-) und bin auf boris' meinung
> gespannt.

Ich bin ein Freund von Komplexitätsreduktion. Wir müssen nicht alles
unterstützen, was der User vielleicht wollen könnte. Wer in der Lage
ist, pgm2 von fhem zu unterscheiden und eigene Anpassungen vornimmt, ist
auch in der Lage, sein Update selbst zu kontrollieren.

Ich habe übrigens die Perl-Module von pgm2 in FHEM integriert (siehe
testing-Branch) und das Verzeichnis www/pgm2 enthält nur
pgm2-spezifische Style Sheets und Javascript, weil das pgm2 und die
anderen Webfrontends ja koexistieren können.

Am Ende ist das für den Anfänger einfacher zu durchschauen.

~ ~ ~

fhemupdate direkt auf SVN operieren zu lassen hat schon seinen Charme.
Allerdings braucht man dann auch wieder SVN in Perl und das ist wieder
ein Knockout für die kleinen Systeme.

Außerdem will man nicht die ganze SVN-Steuerinformation in seiner
Produktivumgebung - führt zumindest zu unnötigen Rückfragen.

Ähnliches gilt für File::RSync
(http://cpansearch.perl.org/src/LEAKIN/File-Rsync-0.43/Rsync.pm), wobei
sich das Perl-Modul noch mitliefern ließe aber vermutlich rsync auf den
kleinen Systemen nicht drauf ist.

~ ~ ~

Wenn es für die o.g. Punkte keine genial einfache Lösung gibt, plädiere
ich dafür, den Mechanismus b.a.w. beizubehalten.

controls.txt manuell zu pflegen ist fehleranfällig, wenn neben Updates
an Dateien auch noch Löschungen, Verschiebungen und Neuzugänge manuell
gepflegt werden müssen. GGf. läßt sich das aber auf die Aktionen UPD
(aktualisieren oder neu) und DEL (löschen) begrenzen und die Datei
automatisch erstellen. Da stecke ich aber nicht drin, um das beurteilen
zu können.

Grüße
Boris

[Martin Fischer]

Am Montag, 2. Juli 2012, 21:20:02 schrieb Dr. Boris Neubert:
> [...]

> Ich bin ein Freund von Komplexitätsreduktion. Wir müssen nicht alles
> unterstützen, was der User vielleicht wollen könnte. Wer in der Lage
> ist, pgm2 von fhem zu unterscheiden und eigene Anpassungen vornimmt, ist
> auch in der Lage, sein Update selbst zu kontrollieren.

das sehe ich etwas anders: wir sollten langsam mal anfangen fhem
einsteigerfreundlicher zu machen. es geht nicht darum ein möglichst hohes mass
an komplexität zu erreichen. ich möchte nun nicht auch schon wieder sämtliche
argumente wiederholen.

update.pm ist (so wie ich es jetzt in gut 900 zeilen code) gebaut habe aus
meiner sicht benutzerfreundlich aber auch so flexibel, das es nicht nur für
den einsteiger geeignet ist, sondern auch der experte damit in einem gewissen
rahmen unterstützung bekommt. desweiteren haben auch wir (besonders rudi) die
möglichkeit künftig über die controls_nnn.txt steueraufgaben vorzunehmen
_ohne_ das die installation darunter leidet. so ist zumindest meine erfahrung
mit meinen tests. das umbenennen, verschieben und löschen von dateien kann
gesteuert sowie komplett neue strukturen "ferngesteuert" eingerichtet werden.

genaueres dazu erkläre ich im laufe des abends noch in einem neuen thread zu
update.pm - release candidate.

> Ich habe übrigens die Perl-Module von pgm2 in FHEM integriert (siehe
> testing-Branch) und das Verzeichnis www/pgm2 enthält nur
> pgm2-spezifische Style Sheets und Javascript, weil das pgm2 und die
> anderen Webfrontends ja koexistieren können.

das ist zwar einerseits gut.. andererseits machst du mir damit einen strich
durch die rechnung. dieses sollten wir nochmal überdenken.

im alten updatefhem.pm konnten ich nur anhand von bestehenden
verzeichnisstrukturen wie "www/pgm2" hardcoded prüfen ob pgm2 installiert ist.
in der vorliegenden variante von update.pm prüfe ich ob das modul FHEMWEB in
fhem bekannt ist. wenn nicht, dann ist mit ziemlicher wahrscheinlichkeit auch
kein pgm2 installiert. wenn 01_FHEMWEB.pm nun wieder mit einer _reinen_ fhem
installation vermischt wird, ist diese prüfung wieder zu nichte!

wir sollten uns dabei besser abstimmen, denn nun habe ich erstmal keinen neuen
ansatz zu differenzieren ob jemand ein "make install" oder "make install-pgm2"
gemacht hat.

irgendwie nervt mich das durcheinander inzwischen auch etwas. wenn dem
benutzer in make eine auswahl zur installation von fhem _mit_ pgm2 und eine
_ohne_ pgm2 angeboten wird, dann müssen wir das auch bei einem update
berücksichtigen. wenn wir dann wieder alles _vermischen_ dann muss in der
konsequenz pgm2 als fester bestandteil von fhem adressiert werden und beim
make keine option mehr angeboten werden.

_diese_ überlegungen hätten aber schon früher kommen können, z.b. als ich nach
dem funktionsumfang gefragt habe. nun macht das sicherlich keinen spass alles
in update.pm zu überarbeiten. ich habe mir da ja nicht umsonst gedanken
gemacht.

alles weitere zu den funktionen von update.pm - wie bereits geschrieben - im
neuen thread.

[Martin Fischer]

Am Mittwoch, 4. Juli 2012, 20:46:39 schrieb Martin Fischer:
> [...]

> genaueres dazu erkläre ich im laufe des abends noch in einem neuen thread zu
> update.pm - release candidate.

verschiebt sich nochmal, da ich just bei schreiben einen fehler gefunden habe.

gruss martin