I’ve never had a reason to write a software updater. However, it’s a program that
Connects to a remote server
Collects some kind of signature for the files currently installed - probably using hashing
Sends the signature to the server
Server determines which binary difference patch files are needed. If the server lacks a patch file for the hash sent by the client, it just sends the base files instead
Updater downloads and installs the base/binary difference files
Well, ok, it’s a few steps, and you might not get it right the first time. But, I recall several different update programs requiring a chain of updates to the updater! Old versions of updaters can’t even be updated to the newest version in one step, either! Somehow, a binary patch of an arbitrary data file is beyond the older version!
Even Microsoft has this problem. I can recall it taking a chain of 5 updates to Windows Update before XP was even able to update!
Why does this happen? Computationally, it shouldn’t. It shouldn’t matter if your using an update runtime written in the 90s, as long as the network protocols are the same, any arbitrary binary patch/base file change should be possible.
Yast on SUSE seems to update itself several times a year — obviously as a separate update. I just assume it is to update security protocols and to adapt to changes in the evolving operating system. And occasionally to update the GUI.
One could decline such updates, and I have no doubt sticking to an earlier YAST version would still update the OS and all the installed programs from the various repositories; but I see little profit in so doing.
EDIT: Looking it up. I see one such change mentioned on FaceBook as
Unsure what that means, but obviously they tinker for improvements.
There could be a chicken and egg issue with the updaters.
A new updater may change the protocol or installation mechanisms in some way. However its own installation cannot make use of these changes - for obvious reasons. So each software updater must be capable of being installed by the previous version, but once the change is made, it may be reasonable for the next version to make use of those new protocols and installation mechanisms. If this happens you have no choice but to either: make multiple special versions of each updater installation that can jump versions, or serially install the updaters. The latter is less work and much less prone to problems.
One reason for multiple updates is that when there are lots of versions in the field, it’s painful to create a single update strategy that works for every possible combination. Instead, you just create each step along the way, and people pick them up starting at whatever version they happen to be at.
Some of the reasons I’ve seen for needing to update the updater:
Security patches - the key has (or is likely to be) compromised, and you need to update to a new key.
File system changes - you have a fundamental change in the file system, and need a special version that understands the change to handle the conversion.
The updater is common across multiple hardware platforms, and a new platform has come out that requires new drivers.
2 , and 5… “For to and from versions which its been thoroughly tested”…
As well , the new age installer is modular, its a few megabytes that downloads the rest of the stuff… so really the first update is to switch to a modular program, and then that program then downloads the updater/installer properly, and then the updater actually runs an actual update step…