autoupdater

Hier können Sie auf Deutsch diskutieren. Bedenken Sie, dass Sie in den englischen Foren mehr Nutzer ansprechen.

Moderators: frik85, EmuandCo, Dr. Fred

naums
Posts: 275
Joined: Sun Feb 21, 2010 9:12 pm
Location: Milkau, Germany
Contact:

Re: autoupdater

Post by naums »

Ich hab mir da schon Gedanken gemacht. Ich glaube vicmarcal hat die Pläne im genannten Post schon beschrieben, also erspare ich mir das hier. Übrigens: alle 6 oder 12 Stunden nach Updates prüfen wäre sinnlos, weil 1. ein commit früher kommt, und 2. Was passiert, wenn der Server grade am bauen der neuen Dateien ist und der Updater holt sich halb die alten, halb die neuen.

Deshalb will ich das so machen, dass es einen Update-server gibt, der sich die aktuelle BootCD holt (von iso.reactos.org), entpackt, die Dateien entpackt und hasht. Der Updater fragt 1. nach, wann das Update geholt wurde (sollte für den Anfang IMMER 24:00 Uhr geholt werden, sodass es eben erstmal nicht zu komplikationen kommt) kuckt nach, welche hash-Werte unterschieden sind, lädt alle neuen Dateien runter, und schaut nach ob sich irgendwas an der Zeit, was das Update geholt wurde geändert hat.

Sollte letzteres JA ergeben, dann hat der Updater sich wahrscheinlich grade Dateien von 2 versch. Versionen geholt und er fängt von vorn an. Problem: Was passiert, wenn ein Update länger als 24h dauert? :D In der Praxis kann man mehrere Server haben, wo einer pro Stunde neue Updates holt, einer pro Tag, einer pro 5 Tage oder sowas. Wäre denkbar, aber inwiefern sinnvoll bleibt zu testen.

Theoretisch sollte ich bis April die erste Version geschafft haben, eher ist wahrscheinlich nicht drin. Dann könnt ihr dann mit Kritik usw. loslegen :D Ein Dienst wird es fürs Erste nicht, sollte allerdings nicht allzu schwer sein - das Programm muss ja nur als Autostart ausgeführt werden, dann aktualisiert es ReactOS vollautomatisch. Brauche ich für einen Windows-Dienst bestimmte Funktionen oder geht das mit while(true) ... ? :D

MfG
nh__
Posts: 11
Joined: Fri Nov 09, 2012 2:08 pm

Re: autoupdater

Post by nh__ »

Wenns eh einen Updateserver gibt sollte der vorgeben bis wo geupdated werden soll.
Das Problem ist, es gibt auch defekte Nightly-Versionen. Auf die will ich nicht updaten wollen, denn dann bootet Ros nicht mehr...
Der Updateserver sollte schon checken ob der Testmanager die Programmtests erfolgreich durchführen konnte und nicht einfach alles (auch defektes) updaten.
User avatar
gonzoMD
Posts: 1077
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany
Contact:

Re: autoupdater

Post by gonzoMD »

Naums: Schaut ersteinmal einfach aus, lässt sich mit Sicherheit auch in einer GUI Applikation anwenden: http://code.msdn.microsoft.com/windowsd ... e-cacf4948

Erklär mir mal bitte nochmal genau warum du das so kompliziert machen möchtest, mit den hashwerten und nicht einfach die Ausgabe von dem Befehl ver mit der SVN XML-Datei abgleichst, dann weißt du zumindest ersteinmal dass das System nicht mehr aktuell ist.
Ein weiterer Vorteil wäre dass man daraus ein Changelog generieren könnte, in dem alle Commitmeldungen von der installierten Version bis zur aktuellen ausließt und ausgibt, bevor letztendlich der Button "Update" geklickt wird.
naums
Posts: 275
Joined: Sun Feb 21, 2010 9:12 pm
Location: Milkau, Germany
Contact:

Re: autoupdater

Post by naums »

Testmanager checken wäre eine Idee. Man könnte aber auch manuell Builds testen. Wäre genau der gleiche Aufwand. Bitte vergesst nicht, dass der Update-Server NICHT auf dem Buildbot laufen wird. Bzw. nicht muss! svn soll nicht gebundlet werden. Das wäre zwar eine Idee, einen knapp 1MB Updater (wenn überhaupt) mit 12 MB SVN zu bündeln, wäre aber extrember overkill. Der Check ob Updates verfügbar sind, wird folgendermaßen aussehen. Der Update-Client hat ne Datei, wo drin steht, wann er das letzte mal geupdatet hat, der Server hat ne Datei, wann er den aktuellen Build geholt hat (und entpackt hat). Vergleicht man die zwei Werte kann in Bruchteilen von Sekunden entschieden sein, dass kein Update verfügbar ist. Commitmeldungen zu verfolgen führt dazu, dass evtl. zu viele Updates in einem Update-Vorgang kommen, dass ein Client mit langsamer Leitung, also immerwieder Dateien verschiedener Versionen holt. Deshalb habe ich bewusst fürs Erste das Update-Intervall für den Server auf 24h gesetzt.

Kurz zu einer GUI-Anwendung: Wenn du die WinAPI verstehst, kannst du gerne anfangen eine GUI zu basteln, es soll aber für mich erstmal Sinn sein einen lauffähigen Updater zu schreiben. Wenn der funktioniert kann eine GUI geschrieben werden, die exakt auf der Konsolenanwendung aufsetzt. Ich habe derzeit weder Lust noch Zeit - damit meine ich ich habe echt NULL Zeit, mich in die WinAPI einzulesen. Der Updater wird kommen, aber nicht vor März, April; bis dahin hab ich noch Prüfungen zu schreiben, auf die ich mich vorbereiten sollte.

Wenn ein kaputter Build geholt wird, dann ist dann dein System halt kaputt. Pech. ReactOS muss derzeit JEDESMAL bei einem Update neu installiert werden, also ist das trotzdem ein Fortschritt. Derzeit, bzw. bis vor kurzem gehen keine DNS-Abfragen in ReactOS. Um solche Fehler abzufangen wird es auch (!) IP-Adressen in den Config-Dateien geben und keine URLs. Erst, wenn alle Dateien an den IPs nicht gefunden wurden, werden die URLs probiert. So fange ich ab, dass DNS-Server unsinnig abgefragt werden bzw. DNS-Abfragen nicht funktionieren.

Ich hab mir bis jetzt schon Gedanken über den Update-Prozess gemacht und es werden noch Verbesserungen beim Schreiben des Codes kommen. Ich mache hier nicht den zweites Schritt vor dem ersten. Lasst mich erstmal eine funktionierende Version zusammenmeiseln, danach können wir gerne über Verbesserungen, GUIs, Interfaces, APIs und Sound und Videountermalung sowie 3D-Grafik beim Updaten reden. (Achtung, Ansätze von Sarkasmus)

Edit: ich hab den Satz, wo GUI drin vorkam anscheinend falsch interpretiert. ...

MfG
Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests