Why does the separation of update and upgrade even exist?

Solution 1:

The history of the difference between update and upgrade is actually pretty cool.

Long, long ago --say around 2000 or so, years before Ubuntu existed--, bandwidth and disk space were much more limited...though expansive compared to mid-1990s. Broadband was just getting started, and dialup was still a vital way of getting online. Big disks were still only a few hundred MB. Apt was shiny and new, radical and revolutionary, built on top of dpkg.

The apt database, when you think about it, is a marvel: It's an accurate-to-the-minute database of all software from all known repositories. It's detailed enough for apt to calculate dependencies and identify available upgrades, yet small enough to transmit over the dial-up modems of the time and to store on the small drives of the time. Updating your database by phone might take minutes over a good connection. While that's a long time now, looking up package updates manually (before apt) could consume hours.

Back then, distros were built differently - no Continuous Integration, no smoke testing (well, not much testing at all!), build farms were just getting started. Upgrades had to be reverted more often than now. Many users chose to not upgrade certain packages for various reasons, or to select only certain upgrades today (to test manually), and other upgrades tomorrow.

Over the subsequent 15-or-so years, the tools have not changed much, which is why we still have separate update and upgrade actions. The user workflow has evolved as distro reliability has improved, and much of the source/update/upgrade management that used to be manual has been slowly hidden behind layers of automation (software-updater, unattended-upgrades).

Modernizing software package tools is one reason that Snaps and AppImage and Flatpack have recently appeared, but that's the next chapter.

Solution 2:

An upgrade is not the only time you might need to apt-get update, and I do not want to upgrade each time I simply want to update the package lists.

An apt-get upgrade working well may depend on apt-get update being run not long ago, but then that is true of apt-get remove and apt-get install as well! Should all of these imply apt-get update? Of course not! As a simple matter of resource efficiency and design cleanness, if an operation is common to multiple other operations, it should be factored out.

Conversely, given that apt-get remove and apt-get install may also depend on apt-get update being recently run to successfully finish, does it make sense to apt-get upgrade for each run of apt-get update? No, again, since what I intend to do may well conflict with what apt-get upgrade will do.

Solution 3:

Whenever you change the software sources, you must run the command sudo apt update in order to refresh the list of available software. Then you can search for available packages in the new software source you just added and/or install them.

The command sudo apt upgrade is the terminal equivalent of upgrading the list of installed packages using the Software Updater application. This is different from the normal workflow of adding a new software source, updating the list of available software to include packages from the new software source, and installing new package(s) from the new software source that you just added, so it's more convenient and less confusing that sudo apt update and sudo apt upgrade are separate commands.

It's also less confusing to separate sudo apt update and sudo apt upgrade because when you run sudo apt update successfully you have confirmed that you have internet connectivity. If there is a problem when running sudo apt upgrade afterwards, the problem is more likely to be a package management issue than an issue with internet connectivity, and the results of sudo apt upgrade will provide clues for diagnosing and solving the problem.