13

I understand that in apt, the command update, updates the list of available packages, but it does not upgrade software that was already installed from these packages.

I also understand that upgrade upgrades any software that I already installed from a package I updated with update as described above.

What was the reason of the Ubuntu/Debian developers to do this splitting of update and upgrade instead work with one command to do both tasks?

This is more of a question on the architectural philosophy of the Ubuntu developers.

Improve this question
3
  • If I am going to install many many apps (and am grouping them, so one command for one group, next command for the next etc), why would I want to download the repo's for each group - by separating the repo.update and the subsequent install steps I can save bandwidth. If I wanted a command to do both, I could script or alias it anyway. The unix way is one command does one thing only anyway so separating fits better with the unix way if 'theological/philosophical' arguments are you thing too.
    – guiverc
    Feb 13, 2018 at 11:47
  • likewise, if I go apt dist-upgrade and hit "n" to cancel, then change my mind I will save bandwidth because it won't 'update' in order to re-do my apt dist-upgrade command... Even if 'dist-upgrade' did the update automatically, there are reasons to 'update' that don't include 'install', 'upgrade' or 'dist-upgrade' so the 'update' command would exist anyway..
    – guiverc
    Feb 13, 2018 at 11:49
  • I've argued that the separation should not exist from the user perspective, and that the action of apt update should just run automatically when required.
    – Robie Basak
    Apr 1, 2018 at 1:01

6 Answers 6

Reset to default
8

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.

Improve this answer
7

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.

Improve this answer
6
+100

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.

Improve this answer
3

They do separate things for many reasons.

One example is a question I posted and self-answered: How can PPAs be removed using GUI?. On this screen we want to remove PPAs not upgrade the software:

Remove PPA.png

After removing a PPA the GUI software automatically runs sudo apt update. If you were to remove a PPA from the command line you need to run sudo apt update after removing a PPA from sources list.

Without a separate apt update function there is no way to remove a PPA!.

Another example is you need to run sudo apt update from command line to refresh sources. Then you can find out what could be upgraded without actually upgrading:

$ apt list --upgradable
Listing... Done
conky-std/xenial 1.10.1-3 amd64 [upgradable from: 1.9.0-4]
google-chrome-stable/stable 65.0.3325.181-1 amd64 [upgradable from: 63.0.3239.132-1]
libxnvctrl0/xenial 390.48-0ubuntu0~gpu16.04.1 amd64 [upgradable from: 387.22-0ubuntu0~gpu16.04.1]
nvidia-settings/xenial 390.48-0ubuntu0~gpu16.04.1 amd64 [upgradable from: 387.22-0ubuntu0~gpu16.04.1]
peek/xenial 1.3.1-0~ppa23~ubuntu16.04.1 amd64 [upgradable from: 1.2.1-0~ppa20~ubuntu16.04.1]

Looking at the output you could decide to have a given package "pinned" or "held back" and not upgraded the next time `sudo apt upgrade" is run. If there were a single "update/upgrade" process you would loose these ability.

Without a separate apt update you can't see what would be upgraded!

Improve this answer
6
  • The second para is false. yum and dnf automatically run the equivalent of an update when doing relevant operations. For example, the equivalent of apt list --upgradable is yum check-update, which updates the package list if it was not updated recently. It's certainly possible for this to work, as can be seen in other package managers.
    – muru
    Apr 6, 2018 at 8:20
  • @muru It's based on this 238 up-vote answer that says you have to run sudo apt update after removing a repository.
    – WinEunuuchs2Unix
    Apr 6, 2018 at 10:05
  • the second --- separated section, then.
    – muru
    Apr 6, 2018 at 10:06
  • Now that you mention it, that is also false. As can be seen from the example of yum/dnf again, the update operation is automatic, so a disabled source is automatically removed from the next operation. Again, something that is entirely possible.
    – muru
    Apr 6, 2018 at 10:12
  • @muru Also, on my system at least, neither yum nor dnf are installed. Installing one of them to replace an apt updatewould increase system overhead and learning time.
    – WinEunuuchs2Unix
    Apr 6, 2018 at 10:13
0

One could ask why to download the program from the formal Ubuntu repository with apt then install it? What difference would it make if you first download it and then install it rather than downloading and installing in one operation?

Well after reading the comments and thinking more on this I understand that this is due to the Unix philosophy, a modular philosophy that basically says "Each program does one thing": First download, then install --- each action with its own dedicated program.

Improve this answer
0

In no distribution, there is one command update-upgrade thing, if it's there, it's nothing but predefined aliases as much I presume. Those aliases can easily be set on Ubuntu too, by editing the ~/.bashrc.

Update is used to resyncronize the repositories and fix any issues there. Then when you Upgrade, you actually ugrade your installed packages. But when you Dist-Upgrade, you upgrade in full. In Arch linux, they emphasise on full upgrade with Syu. You can do the same in Ubuntu. In full upgrade, you actually resolve any dependency issue system wise, that may arise in partial upgrade.

Hope it helps. Please excuse the raw text as writing on phone.

Improve this answer
1
  • 2
    yum and dnf automatically do the equivalent of an update on most operations if the cached data is old enough. See, for example, discussion on changing that behaviour in dnf: lwn.net/Articles/750334
    – muru
    Apr 3, 2018 at 7:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.