On a Debian or Ubuntu host, what is the difference between `apt upgrade`, `apt full-upgrade` and `apt-get dist-upgrade`, and which of them is allowed to remove an installed package?

## The same job, three permission levels The three commands all mean "bring installed packages up to their candidate versions". What separates them is the set of actions the resolver is allowed to take when the straightforward upgrade does not fit. | Command | May install new packages | May remove packages | |---|---|---| | `apt-get upgrade` | no | no | | `apt upgrade` | yes | no | | `apt full-upgrade` = `apt-get dist-upgrade` | yes | yes | `apt full-upgrade` and `apt-get dist-upgrade` are not two behaviours with a modern and a legacy name for different things — they are the same resolver mode, renamed when the `apt` front end was introduced because "dist-upgrade" misled people into thinking it moved you to the next distribution release. It does not. ## "The following packages have been kept back" This line is the visible edge of the permission model. A package is held back when upgrading it would need an action the command is not allowed to take. The classic case is the kernel. On Ubuntu, `linux-image-generic` is a meta-package that depends on a versioned package such as `linux-image-6.8.0-45-generic`. Upgrading the meta-package therefore requires *installing a package that is not currently on the system*. Under `apt-get upgrade` that is forbidden, so it is kept back and the machine quietly stops taking kernel updates. Under `apt upgrade` the new kernel package is installed and the upgrade completes. `apt-get upgrade --with-new-pkgs` gives the old command the same permission explicitly. The second case is a conflict: the new version of A conflicts with installed package B, or a library transition means B is no longer built. Resolving that needs a removal, so both `upgrade` forms hold it back and only `full-upgrade` can proceed. On Ubuntu there is a third, non-structural cause: phased updates. An update can be released to a growing percentage of machines over several days, and a machine not yet in the phase sees the package as kept back even though nothing depends on anything new. It resolves itself as the phase widens. ## Why the distinction matters operationally ``` apt-get -s full-upgrade ``` Simulating first is the habit worth having, because the difference between the commands is precisely the difference between a routine patch run and one that can take a service away. A `full-upgrade` on a neglected box can propose removing something a colleague installed by hand, or a metapackage whose dependencies changed, and the only warning is the `The following packages will be REMOVED` block in the plan. Read it. In unattended contexts, the conservative `upgrade` is the right default for exactly this reason — the failure mode of a kept-back package is a missed update you can see in monitoring, while the failure mode of an unsupervised removal is an outage. The opposite mistake is never running `full-upgrade` at all. Packages accumulate in the kept-back list, security updates sit unapplied because they arrived in a transition, and the eventual upgrade is far larger and riskier than a series of small supervised ones. The healthy pattern is `upgrade` frequently and unattended, `full-upgrade` deliberately on a schedule with the plan reviewed. ## What none of them do None of these commands move the machine to a new distribution release. On Debian the documented procedure is to edit the sources to the new suite, then run `apt update`, `apt upgrade --without-new-pkgs`, and finally `apt full-upgrade` — the minimal-upgrade step first, deliberately, so the core is consistent before the resolver is allowed to make big changes. On Ubuntu the supported path is `do-release-upgrade`, which handles sources rewriting, third-party repository disabling and a recovery shell that a bare `full-upgrade` does not. Also worth separating: `apt upgrade` never removes, but `apt autoremove` exists specifically to remove packages that were pulled in automatically and are no longer depended on. Some people wire `autoremove` into their patch runs; on a server that is where an unexpected kernel or library removal is most likely to come from, so it deserves the same plan review. ## Reading the summary line Every apt transaction ends with a count: upgraded, newly installed, to remove, not upgraded. The last number is the kept-back count, and on a fleet it is the number worth alerting on. A machine sitting at "12 not upgraded" for weeks is telling you that your conservative patch job has hit something it is not permitted to resolve, and that somebody needs to run the supervised command.