Difference between revisions of "ReactOS Update"

From ReactOS Wiki
Jump to: navigation, search
m (Update Metadata)
m (Package Management)
 
(26 intermediate revisions by 11 users not shown)
Line 1: Line 1:
As ReactOS grows further in usability and functionality, it would be prudent to have a utility, ReactOSUpdate, to download and install updates without  in an easy and fast way for end users, with a nice "ReactOS Update" button to make it look like Windows. :-)
+
As ReactOS grows further in usability and functionality, it would be prudent to have a utility, ReactOSUpdate, to download and install updates in an easy and fast way for end users, with a nice "ReactOS Update" button to make it look similar to what Windows has.
  
----
+
== rsync-update concept #1 ==
What about [http://rsync.samba.org/ rsync] for retrieving updates in system directories?
 
  
== rsync-update concept #1 ==
+
We would probably need a second directory where the ReactOS core system files get stored too. This might be something like DLLCache from Windows (the installation routine only needs to install these system files twice). rsync updates the files in DLLCache. A reimplementation of [[SFC]] would then copy the new files to their usual destination after reboot.
we would probably need a second directory where the reactos core system files get stored too. this might be something like "[[dllcache]]" from windows (the installation routine only needs to install these system files twice). rsync updates the files in dllCache. a reimplementation of [[SFC]] would then copy the new files to their usual destination after reboot.
 
  
 
=== what do we need? ===
 
=== what do we need? ===
* networking and TcpIpDotSys (network is NOT required for syncing! you can also rsync from a local source - e.g. for testing or updating from cdrom)
+
 
 +
* networking and [[TCPIP.SYS]] (network is NOT required for syncing! you can also rsync from a local source - e.g. for testing or updating from CD-ROM)
 
* [http://rsync.samba.org/nt.html rsync for our platform] (already available)
 
* [http://rsync.samba.org/nt.html rsync for our platform] (already available)
* A version of [[SFC]]
+
* A version of SFC
* a (secure!) rsync server providing us with files
+
* A (secure!) rsync server providing us with files
 
 
----
 
  
 
== ReactOS Update (ReactUpdate) concept #2 ==
 
== ReactOS Update (ReactUpdate) concept #2 ==
Line 21: Line 18:
 
* Checks itself to ensure it hasn't been tampered with (Digital Signature/checksum).
 
* Checks itself to ensure it hasn't been tampered with (Digital Signature/checksum).
 
* Checks against it's ACL if the UserID invoking it has the right to do so.
 
* Checks against it's ACL if the UserID invoking it has the right to do so.
** If not, it can prompt with a RunAs box to enter valid credentails (Like MacOS X does with it's control panel).
+
** If not, it can prompt with a RunAs box to enter valid credentials (Like MacOS X does with its control panel).
*** If RunAs is unavailible or unimplemented, gives an error along the lines of "Your user account has not been granted permission to run ReactOS Update".
+
*** If RunAs is unavailable or unimplemented, gives an error along the lines of "Your user account has not been granted permission to run ReactOS Update."
** If the UserID is allowed, it silently continues to the next step
+
** If the UserID is allowed, it <del>silently</del> continues to the next step, asks for your password
 
* Check if there's a previous update/restart pending.
 
* Check if there's a previous update/restart pending.
** If so, state that for some other reason the system should be restarted before any updating is attempted (Maybe give an option to go ahead anyway, with with sufficent warning (EG. "It is strongly recommended you restart your system before attempting to update ReactOS")).
+
** If so, state that for some other reason the system should be restarted before any updating is attempted (Maybe give an option to go ahead anyway, with sufficient warning (e.g. "It is strongly recommended you restart your system before attempting to update ReactOS")).
 
** If not keep going.
 
** If not keep going.
* Ask the user how they want to update: Over the Internet (Recommended) (Suboption of a local update server), or via a local update source.
+
* Ask the user how they want to update: Over the Internet (Recommended) (Sub-option of a local update server), or via a local update source.
 
** If over the Internet normally, continue.
 
** If over the Internet normally, continue.
*** If a local update server, ask for the name/IP (If not preselected by the Administrator), and if required credentials (Using a standard connect dailog box)
+
*** If a local update server, ask for the name/IP (If not preselected by the Administrator), and if required credentials (Using a standard connect dialog box)
** If a local source, ask for the path to the "INFO.UPD" (Or whatever the update data file (Think sortof like .inf file paths thatare always requested for always requested on driver installs) is called in the end). If this is the case, in the following steps, read "The local media" instead of a remote server where network transactions are being discussed.
+
** If a local source, ask for the path to the "INFO.UPD" (Or whatever the update data file (Think sort of like .inf file paths that are always requested for always requested on driver installs) is called in the end). If this is the case, in the following steps, read "The local media" instead of a remote server where network transactions are being discussed.
 
* I'm not sure about this step: How for it to determine the ReactOS update sites DNS and/or IP and not be liable to spoofing. The best thing I can come up with is if the DNS is going to change, have the old one only offer an update to ReactOSUpdate that will redirect it to the correct one.
 
* I'm not sure about this step: How for it to determine the ReactOS update sites DNS and/or IP and not be liable to spoofing. The best thing I can come up with is if the DNS is going to change, have the old one only offer an update to ReactOSUpdate that will redirect it to the correct one.
** If using a locally specified update server, goto the one supplied by the user.
+
** If using a locally specified update server, go to the one supplied by the user.
* Open an HTTPS connection to the update site (Probably something like rosupdate.reactos.org, update.reactos.org, os.update.reactos.org, etc. which incedentally, could function as web-based update sites for ROS).
+
* Open an HTTPS connection to the update site (Probably something like rosupdate.reactos.org, update.reactos.org, os.update.reactos.org, etc. which incidentally, could function as web-based update sites for ROS).
**''HTTPS connections are a resource drain on the server and prevent cache-ing, which is important for large downloads. Besides, you don't really need them if the files themselves are signed.''
+
**''HTTPS connections are a resource drain on the server and prevent caching, which is important for large downloads. Besides, you don't really need them if the files themselves are signed.''
* Report the ReactOSUpdate application version number and if the server reports it ourdated, download the information to download and install the most up-do-date version.
+
* Report the ReactOSUpdate application version number and if the server reports it outdated, download the information to download and install the most up-do-date version.
** If there are update, present them as the only update and state that they need to install that to recive other updates.
+
** If there are updates, present them as the only update and state that they need to install that to receive other updates.
 
** If not, continue on.
 
** If not, continue on.
 
* Download from the server the list of all the files that have updates, the new versions, sizes, and other metadata (Full list later down the page)
 
* Download from the server the list of all the files that have updates, the new versions, sizes, and other metadata (Full list later down the page)
 
* Format and present this to the user in the application.
 
* Format and present this to the user in the application.
** If any updates are of immediately serious import (EG. There's a very easily exploited TCP/IP buffer overflow giving SYSTEM access and there's a rapidly spreading worm (Blaster-like) that exploits this) ReactOSUpdate may take immediate action (Block the affected ports, stop the affected services, or completely kill certain parts of the system untill updated (There should be a user preference to disable this or to ask 1st).
+
** If any updates are of immediately serious import (e.g. There's a very easily exploited TCP/IP buffer overflow giving SYSTEM access and there's a rapidly spreading worm (Blaster-like) that exploits this) ReactOSUpdate may take immediate action (Block the affected ports, stop the affected services, or completely kill certain parts of the system until updated (There should be a user preference to disable this or to ask 1st).
** Seperate the updates into different sections based on their importance, but also by size, time to download, etc.
+
** Separate the updates into different sections based on their importance, but also by size, time to download, etc.
** Also have tabs (Or a different means) to seperate the updates which need to be installed in their own session, independent of others
+
** Also have tabs (Or a different means) to separate the updates which need to be installed in their own session, independent of others
 
** Have an option, selected by default, to delete the updates after installation.
 
** Have an option, selected by default, to delete the updates after installation.
 
*** A further option, download the updates but don't install them automatically.
 
*** A further option, download the updates but don't install them automatically.
 
** Have an option, preferably selected by default, to not accept any network connections before the updates have been run for the first time (to solve the "I can't update without getting blaster" problem after you run an installation or image)
 
** Have an option, preferably selected by default, to not accept any network connections before the updates have been run for the first time (to solve the "I can't update without getting blaster" problem after you run an installation or image)
 
* The user then selects the updates to install and indicates to continue  
 
* The user then selects the updates to install and indicates to continue  
** Check that no updates which need to be installed seperately are selected with others
+
** Check that no updates which need to be installed separately are selected with others
*** If so, give an error listing the 2 options and allowing to continue with one or the other (Default to the one with the higher criticality), go back and review the selections, or cancel the update.
+
*** If so, give an error listing the 2 options and allowing to continue with one or the other (Default to the one with the higher priority), go back and review the selections, or cancel the update.
 
** If the download size is significant compared to the speed of their connection to the update server, warn against significant delays and possible toll charged.
 
** If the download size is significant compared to the speed of their connection to the update server, warn against significant delays and possible toll charged.
 
** If neither of these apply, the keep going.
 
** If neither of these apply, the keep going.
 
* Warn the user that once the updates are downloaded, the system will need to be restart and that all unsaved work will be lost, etc, etc. Give them fair warning and the ability to gracefully back out (If there are updates of vital import this could be blocked/bypassed, or "strongly recommended" to continue).
 
* Warn the user that once the updates are downloaded, the system will need to be restart and that all unsaved work will be lost, etc, etc. Give them fair warning and the ability to gracefully back out (If there are updates of vital import this could be blocked/bypassed, or "strongly recommended" to continue).
 
* Over secured connection (HTTPS or SFTP for example) download the selected updates to a directory on the hard disk (\ReactOS\Downloaded Updates, for example) and verify them.
 
* Over secured connection (HTTPS or SFTP for example) download the selected updates to a directory on the hard disk (\ReactOS\Downloaded Updates, for example) and verify them.
** If any fail verification, delete and redownload
+
** If there's any fail verification, delete and redownload
 
* When all the updates are downloaded install them using one of the following methods (Note, I have no idea which is best or even possible, I'll leave that for someone else to determine)
 
* When all the updates are downloaded install them using one of the following methods (Note, I have no idea which is best or even possible, I'll leave that for someone else to determine)
  
Line 62: Line 59:
  
 
Method 2:
 
Method 2:
* Move the files to a seperate directory.
+
* Move the files to a separate directory.
 
* Have the kernel load a program (Probably under the BootExecute key in the Registry) that will load on early startup
 
* Have the kernel load a program (Probably under the BootExecute key in the Registry) that will load on early startup
 
* Request a reboot.
 
* Request a reboot.
 
* Once the program loads it kills the old copies, moves the new ones over, and makes a log somewhere.
 
* Once the program loads it kills the old copies, moves the new ones over, and makes a log somewhere.
  
Method 2.1 (Slighly different version of 2):
+
Method 2.1 (Slightly different version of 2):
* Install (In \ROSBootUpdate, for instance) a minimal kernel and the files to be copied and put it in the FreeLoader bootmenu (As "ReactOS 1 SP1 Installer", say) and make it default with a very short timedelay.
+
* Install (In \ROSBootUpdate, for instance) a minimal kernel and the files to be copied and put it in the FreeLoader boot menu (As "ReactOS 1 SP1 Installer," say) and make it default with a very short time delay.
 
* When loaded, check itself and the files to be sure they're correct.
 
* When loaded, check itself and the files to be sure they're correct.
 
** If they are invalid, state as much with possible reasons why, and jump to the 4th from last step (In this revision).
 
** If they are invalid, state as much with possible reasons why, and jump to the 4th from last step (In this revision).
** If all are valid, contine.
+
** If all are valid, continue.
 
* Locate the directories and files to be replaced.
 
* Locate the directories and files to be replaced.
 
* Erase the old files and copy the new ones over.
 
* Erase the old files and copy the new ones over.
Line 80: Line 77:
 
=== Update Metadata ===
 
=== Update Metadata ===
  
* English (Or whatever language is specified ;)) description of the componment(s) affected.
+
* English (Or whatever language is specified ;)) description of the component(s) affected.
 
* New and currently installed versions
 
* New and currently installed versions
 
* Sizes of update downloads
 
* Sizes of update downloads
Line 90: Line 87:
 
*** Misspelled "ReactOS" in something
 
*** Misspelled "ReactOS" in something
 
** Minor bug  
 
** Minor bug  
*** Pressing "OK" somewhere doesn't save chnages
+
*** Pressing "OK" somewhere doesn't save changes
 
** Moderate bug  
 
** Moderate bug  
 
*** Pressing "OK" somewhere freezes the Desktop/Shell
 
*** Pressing "OK" somewhere freezes the Desktop/Shell
Line 96: Line 93:
 
*** ReactOS can be crashed by pressing "OK" somewhere, by sending a malformed TCP packet the system gives a BSOD
 
*** ReactOS can be crashed by pressing "OK" somewhere, by sending a malformed TCP packet the system gives a BSOD
 
** Critical bug  
 
** Critical bug  
*** A very easily exploitable hole or other bug which can lead to compromise of sensetive/confidential information, compromise of the system at elevated privledges (Administrator or SYSTEM), or corruption of vital files/directories.
+
*** A very easily exploitable hole or other bug which can lead to compromise of sensitive/confidential information, compromise of the system at elevated privileges (Administrator or SYSTEM), or corruption of vital files/directories.
 
** Extremely Critical bug
 
** Extremely Critical bug
 
*** Same as Critical, but with evidence of "In the wild" use (Virus with Blaster-like proportions)
 
*** Same as Critical, but with evidence of "In the wild" use (Virus with Blaster-like proportions)
Line 112: Line 109:
 
** Probably [http://www.apache.org/ Apache] and something else for SFTP
 
** Probably [http://www.apache.org/ Apache] and something else for SFTP
 
* A valid SSL certificate
 
* A valid SSL certificate
** Possibly selfsigned, or from VeriSign, Thawte, or similar.
+
** Possibly self-signed, or from VeriSign, Thawte, or similar.
 
* Probably as ROS grows more popular a dedicated line for this server (Which should also become a dedicated and formidable server), or regional update servers.
 
* Probably as ROS grows more popular a dedicated line for this server (Which should also become a dedicated and formidable server), or regional update servers.
** Appropriate, probably a seperate DNS (os.update.reactos.org). Later as popularity, complexity and hence updates and downloads grow, local mirrors (os.update.reactos.org.nl, .ru, .us, .mx, .au, etc), if you can update from version to version via ROSUpdate (EG. 0.6.0 > 0.7.0) then probably sub-servers for those updates alone (070.os.update.reactos.org), and possibly multiple servers in the same area (philadelphia.os.update.reactos.us, eastfalls.philadelphia.pa.update.reactos.us). I know these scenarios are FAR into the future if they will ever occur, but it's good to have a plan.
+
** Appropriate, probably a separate DNS (os.update.reactos.org). Later as popularity, complexity and hence updates and downloads grow, local mirrors (os.update.reactos.org.nl, .ru, .us, .mx, .au, etc), if you can update from version to version via ROSUpdate (e.g. 0.6.0 > 0.7.0) then probably sub-servers for those updates alone (070.os.update.reactos.org), and possibly multiple servers in the same area (philadelphia.os.update.reactos.us, eastfalls.philadelphia.pa.update.reactos.us). I know these scenarios are FAR into the future if they will ever occur, but it's good to have a plan.
 +
* A binary diff/patch utility
 +
** [https://www.chromium.org/developers/design-documents/software-updates-courgette courgette] is a great one
 +
 
 +
== Package Management ==
 +
 
 +
As Linux and MS Windows have developed a method of updating over some time now - are there any shortfalls in currently adopted methods? We should aim to devise an update mechanism that takes the best aspects of Windows Update and Linux package management (such as rpm). The package management utility should have a duty to keep track of orphaned packages/files/libraries. --[[User:Rebroad|Rebroad]] 17:59, 31 Mar 2005 (CEST)
 +
:Yes, I would like to be able to apply non-kernel level OS updates without reboot like DPkg/APT and RPM/whatever package management system. [[User:Erkinalp|Erkinalp]] ([[User talk:Erkinalp|talk]]) 18:37, 1 February 2014 (UTC)
 +
 
 +
 
 +
Possible Method by Packages :
 +
* Use [[Rosapps|ReactOS Apps]] to manage the update of OS.
 +
* Check the release version of ReactOS.
 +
* Check if updates are available for this release. (if you check manually and no update is available, display "No update is available. Check later.")
 +
* If available, display a message "Update(s) are available. A restart is required.". Ask what to do ("Install now" / "Recall me in 1 hour" / "Recall me in 6 hours" / "Recall me tomorrow" / "Don't install for now")
 +
* If you accept, download the packages (like KB in Windows) in function of the release detected, in the same folder as Windows C:\ReactOS\SoftwareDistribution\Download
 +
* Display a progress bar
 +
* Made a restoration point or copy old files in a folder in case of issue, during the download.
 +
* When the download and the save are finalised, install the new packages.
 +
* Made a log file of the installation C:\ReactOS\Logs.
 +
* If there is a problem :
 +
** Stop the installation.
 +
** Display a message "The update(s) have been aborted. Error xxx."
 +
** Recopy the older files in good place or restore the restoration point.
 +
** Reboot.
 +
* If all is fine :
 +
** Display a message "Update Successful. A manual restart is required." with two buttons, "Restart now" and another "Later", a countdown timer of 25 seconds will be displayed too and if there is no answer, reboot after the countdown.
 +
 
 +
[[Category:Ideas]]

Latest revision as of 13:13, 30 August 2018

As ReactOS grows further in usability and functionality, it would be prudent to have a utility, ReactOSUpdate, to download and install updates in an easy and fast way for end users, with a nice "ReactOS Update" button to make it look similar to what Windows has.

rsync-update concept #1

We would probably need a second directory where the ReactOS core system files get stored too. This might be something like DLLCache from Windows (the installation routine only needs to install these system files twice). rsync updates the files in DLLCache. A reimplementation of SFC would then copy the new files to their usual destination after reboot.

what do we need?

  • networking and TCPIP.SYS (network is NOT required for syncing! you can also rsync from a local source - e.g. for testing or updating from CD-ROM)
  • rsync for our platform (already available)
  • A version of SFC
  • A (secure!) rsync server providing us with files

ReactOS Update (ReactUpdate) concept #2

Have a local app called rosupate.exe (or similar) that lives in the \ReactOS or \ReactOS\system32 directory and, when launched would follow this process:

  • Checks itself to ensure it hasn't been tampered with (Digital Signature/checksum).
  • Checks against it's ACL if the UserID invoking it has the right to do so.
    • If not, it can prompt with a RunAs box to enter valid credentials (Like MacOS X does with its control panel).
      • If RunAs is unavailable or unimplemented, gives an error along the lines of "Your user account has not been granted permission to run ReactOS Update."
    • If the UserID is allowed, it silently continues to the next step, asks for your password
  • Check if there's a previous update/restart pending.
    • If so, state that for some other reason the system should be restarted before any updating is attempted (Maybe give an option to go ahead anyway, with sufficient warning (e.g. "It is strongly recommended you restart your system before attempting to update ReactOS")).
    • If not keep going.
  • Ask the user how they want to update: Over the Internet (Recommended) (Sub-option of a local update server), or via a local update source.
    • If over the Internet normally, continue.
      • If a local update server, ask for the name/IP (If not preselected by the Administrator), and if required credentials (Using a standard connect dialog box)
    • If a local source, ask for the path to the "INFO.UPD" (Or whatever the update data file (Think sort of like .inf file paths that are always requested for always requested on driver installs) is called in the end). If this is the case, in the following steps, read "The local media" instead of a remote server where network transactions are being discussed.
  • I'm not sure about this step: How for it to determine the ReactOS update sites DNS and/or IP and not be liable to spoofing. The best thing I can come up with is if the DNS is going to change, have the old one only offer an update to ReactOSUpdate that will redirect it to the correct one.
    • If using a locally specified update server, go to the one supplied by the user.
  • Open an HTTPS connection to the update site (Probably something like rosupdate.reactos.org, update.reactos.org, os.update.reactos.org, etc. which incidentally, could function as web-based update sites for ROS).
    • HTTPS connections are a resource drain on the server and prevent caching, which is important for large downloads. Besides, you don't really need them if the files themselves are signed.
  • Report the ReactOSUpdate application version number and if the server reports it outdated, download the information to download and install the most up-do-date version.
    • If there are updates, present them as the only update and state that they need to install that to receive other updates.
    • If not, continue on.
  • Download from the server the list of all the files that have updates, the new versions, sizes, and other metadata (Full list later down the page)
  • Format and present this to the user in the application.
    • If any updates are of immediately serious import (e.g. There's a very easily exploited TCP/IP buffer overflow giving SYSTEM access and there's a rapidly spreading worm (Blaster-like) that exploits this) ReactOSUpdate may take immediate action (Block the affected ports, stop the affected services, or completely kill certain parts of the system until updated (There should be a user preference to disable this or to ask 1st).
    • Separate the updates into different sections based on their importance, but also by size, time to download, etc.
    • Also have tabs (Or a different means) to separate the updates which need to be installed in their own session, independent of others
    • Have an option, selected by default, to delete the updates after installation.
      • A further option, download the updates but don't install them automatically.
    • Have an option, preferably selected by default, to not accept any network connections before the updates have been run for the first time (to solve the "I can't update without getting blaster" problem after you run an installation or image)
  • The user then selects the updates to install and indicates to continue
    • Check that no updates which need to be installed separately are selected with others
      • If so, give an error listing the 2 options and allowing to continue with one or the other (Default to the one with the higher priority), go back and review the selections, or cancel the update.
    • If the download size is significant compared to the speed of their connection to the update server, warn against significant delays and possible toll charged.
    • If neither of these apply, the keep going.
  • Warn the user that once the updates are downloaded, the system will need to be restart and that all unsaved work will be lost, etc, etc. Give them fair warning and the ability to gracefully back out (If there are updates of vital import this could be blocked/bypassed, or "strongly recommended" to continue).
  • Over secured connection (HTTPS or SFTP for example) download the selected updates to a directory on the hard disk (\ReactOS\Downloaded Updates, for example) and verify them.
    • If there's any fail verification, delete and redownload
  • When all the updates are downloaded install them using one of the following methods (Note, I have no idea which is best or even possible, I'll leave that for someone else to determine)

Method 1:

  • Overwrite the files as they stand.
  • Verify the new ones.
  • Request a reboot.

Method 2:

  • Move the files to a separate directory.
  • Have the kernel load a program (Probably under the BootExecute key in the Registry) that will load on early startup
  • Request a reboot.
  • Once the program loads it kills the old copies, moves the new ones over, and makes a log somewhere.

Method 2.1 (Slightly different version of 2):

  • Install (In \ROSBootUpdate, for instance) a minimal kernel and the files to be copied and put it in the FreeLoader boot menu (As "ReactOS 1 SP1 Installer," say) and make it default with a very short time delay.
  • When loaded, check itself and the files to be sure they're correct.
    • If they are invalid, state as much with possible reasons why, and jump to the 4th from last step (In this revision).
    • If all are valid, continue.
  • Locate the directories and files to be replaced.
  • Erase the old files and copy the new ones over.
  • Remove the update entry from FreeLdr.ini
  • Add to the BootExecute key of the Registry a command to remove the \ROSBootUpdate directory and itself.
  • Restart.

Update Metadata

  • English (Or whatever language is specified ;)) description of the component(s) affected.
  • New and currently installed versions
  • Sizes of update downloads
    • Compute the approximate download time locally (Maybe using the time it took to download the updates list as a factor?).
  • Severity (Examples/definitions in subpoints)
    • New feature
      • Support for IPX/SPX
    • Trivial bug
      • Misspelled "ReactOS" in something
    • Minor bug
      • Pressing "OK" somewhere doesn't save changes
    • Moderate bug
      • Pressing "OK" somewhere freezes the Desktop/Shell
    • Severe bug
      • ReactOS can be crashed by pressing "OK" somewhere, by sending a malformed TCP packet the system gives a BSOD
    • Critical bug
      • A very easily exploitable hole or other bug which can lead to compromise of sensitive/confidential information, compromise of the system at elevated privileges (Administrator or SYSTEM), or corruption of vital files/directories.
    • Extremely Critical bug
      • Same as Critical, but with evidence of "In the wild" use (Virus with Blaster-like proportions)
        • Will default to stopping the affected part (If possible) during/before update.
  • Reboot required? (Should aim to need only for kernel changes).
  • Individual installation required?

What's needed

  • Networking / TCPIP.SYS (Ideally)
  • A local DLL with crypto functions (checksum, digital signatures, etc)
    • WINE is working on one
  • An HTTPS/SFTP client in the OS
  • An HTTPS/SFTP server
    • Probably Apache and something else for SFTP
  • A valid SSL certificate
    • Possibly self-signed, or from VeriSign, Thawte, or similar.
  • Probably as ROS grows more popular a dedicated line for this server (Which should also become a dedicated and formidable server), or regional update servers.
    • Appropriate, probably a separate DNS (os.update.reactos.org). Later as popularity, complexity and hence updates and downloads grow, local mirrors (os.update.reactos.org.nl, .ru, .us, .mx, .au, etc), if you can update from version to version via ROSUpdate (e.g. 0.6.0 > 0.7.0) then probably sub-servers for those updates alone (070.os.update.reactos.org), and possibly multiple servers in the same area (philadelphia.os.update.reactos.us, eastfalls.philadelphia.pa.update.reactos.us). I know these scenarios are FAR into the future if they will ever occur, but it's good to have a plan.
  • A binary diff/patch utility

Package Management

As Linux and MS Windows have developed a method of updating over some time now - are there any shortfalls in currently adopted methods? We should aim to devise an update mechanism that takes the best aspects of Windows Update and Linux package management (such as rpm). The package management utility should have a duty to keep track of orphaned packages/files/libraries. --Rebroad 17:59, 31 Mar 2005 (CEST)

Yes, I would like to be able to apply non-kernel level OS updates without reboot like DPkg/APT and RPM/whatever package management system. Erkinalp (talk) 18:37, 1 February 2014 (UTC)


Possible Method by Packages :

  • Use ReactOS Apps to manage the update of OS.
  • Check the release version of ReactOS.
  • Check if updates are available for this release. (if you check manually and no update is available, display "No update is available. Check later.")
  • If available, display a message "Update(s) are available. A restart is required.". Ask what to do ("Install now" / "Recall me in 1 hour" / "Recall me in 6 hours" / "Recall me tomorrow" / "Don't install for now")
  • If you accept, download the packages (like KB in Windows) in function of the release detected, in the same folder as Windows C:\ReactOS\SoftwareDistribution\Download
  • Display a progress bar
  • Made a restoration point or copy old files in a folder in case of issue, during the download.
  • When the download and the save are finalised, install the new packages.
  • Made a log file of the installation C:\ReactOS\Logs.
  • If there is a problem :
    • Stop the installation.
    • Display a message "The update(s) have been aborted. Error xxx."
    • Recopy the older files in good place or restore the restoration point.
    • Reboot.
  • If all is fine :
    • Display a message "Update Successful. A manual restart is required." with two buttons, "Restart now" and another "Later", a countdown timer of 25 seconds will be displayed too and if there is no answer, reboot after the countdown.