Update and Install Packages Safely with apt

apt can update, install and remove packages in one breath, and the only thing keeping that safe is reading its plan before you confirm it. This guide gets you through inspecting a package, refreshing the indexes, installing one package and applying upgrades, with every destructive decision still visible. Allow 15 minutes for a normal update and one installation. The examples match APT 2.8.3 on amd64, from the Ubuntu Noble updates repository.

You need a shell, a working package source configuration, and an account allowed to use sudo for changes to the system package database. Reading package information is normally unprivileged. Keep a terminal open for the command output: APT's proposed actions are the safety check, not background noise.

1. Confirm the APT version and package state

Start by checking what is installed and which architecture APT is using:

$ apt --version
apt 2.8.3 (amd64)
$ apt list --installed apt
Listing...
apt/noble-updates,noble-updates,now 2.8.3 amd64 [installed]

Your repository suite and package version may differ. The version matters because apt is an interactive end-user interface, and behaviour can change between versions. The manpage itself recommends the more stable apt-get and apt-cache for scripts. Use apt at the prompt for its readable output; use a dedicated tool for automation.

2. Inspect before changing anything

Use search to find package names and show to inspect metadata, dependencies and download information. Neither command installs or removes anything:

$ apt search '^curl$'
$ apt show curl

The search pattern is a regular expression. Anchoring it with ^ and $ asks for the exact package name, which avoids a long list of similarly named results. If the result is empty or stale, refresh the indexes in the next step. For an installed package, apt list --installed NAME is a quick state check; replace NAME with the package you are investigating.

Before removing anything, run apt show NAME and read the proposed package changes. Ordinary removal leaves most modified system configuration files behind, while purge removes packaged configuration files too. Neither operation touches data in a user's home directory, but application data can still live elsewhere, so check the package documentation and service state first.

3. Refresh package indexes

Run the update operation with elevated privileges:

$ sudo apt update

update downloads package information from every configured source. It does not upgrade installed packages. A successful run ends with a summary of fetched data and package lists; a mirror, DNS, signature or repository configuration error leaves the indexes partly or wholly stale.

Verify the result by asking for packages that can be upgraded:

$ apt list --upgradable

An empty list is a valid result. The command may print a notice that its interface is not stable for scripting, that is a reason to avoid parsing it in automation, not evidence of failure. A non-zero exit status means an error: APT documents status 0 for normal operation and decimal 100 for an error.

4. Install one package and review the plan

Replace the example name with a package you have identified. This changes the system and normally needs sudo:

$ sudo apt install curl

APT displays the packages it will install, upgrade or remove, followed by the download and disk-space totals. Read that list before accepting it: a package name can match a pattern, and a dependency solution can pull in more packages than the name at the prompt suggests.

To select an exact version, append = and the version shown by your package metadata:

$ apt show curl
$ sudo apt install curl=REPLACE_WITH_VERSION

Do not copy the placeholder literally. If more than one release is configured, a package can also be selected with /REPLACE_WITH_SUITE_OR_CODENAME. Check the candidate version first with apt-cache policy curl when you need to see every available version.

To undo an accidental ordinary removal, install the package again. Use purge only after checking that you really want the packaged configuration files gone:

$ sudo apt remove PACKAGE_NAME
$ sudo apt install PACKAGE_NAME

# Destructive: removes packaged configuration files as well.
$ sudo apt purge PACKAGE_NAME

These are recovery examples, not a reason to skip the confirmation prompt. Keep application-specific data and backups separate from APT's package state.

5. Apply upgrades with the right boundary

After a successful update, the conservative upgrade operation is:

$ sudo apt upgrade

upgrade installs available upgrades but does not remove installed packages. If an upgrade would require a removal, that package is simply not upgraded, which makes the proposed removal list a useful boundary for a routine maintenance window.

Use full-upgrade only once you have reviewed a plan that may remove packages to complete the system-wide upgrade:

$ sudo apt full-upgrade

Use autoremove with the same care:

$ sudo apt autoremove

It proposes packages that were automatically installed as dependencies and are no longer needed. Review the list for tools or libraries you still use. If a useful package is marked for automatic removal, mark it as manually installed with sudo apt-mark manual PACKAGE_NAME, then rerun the proposal.

6. Make a small, reversible configuration change

APT reads configuration in a defined order: the file named by APT_CONFIG, valid files in the parts directory, the main file, binary-specific settings, then command-line options. Files in /etc/apt/apt.conf.d/ are read in alphanumeric order when their names use the accepted characters and no extension or a .conf extension. That ordering explains why a later fragment or an -o option can override an earlier value.

For a one-off test, prefer -o so there is no file to forget. This example changes only the current invocation's download retry count:

$ apt -o Acquire::Retries=3 --version
apt 2.8.3 (amd64)

For a persistent setting, create a clearly named fragment as root, keeping the value on one line with a quoted value and a trailing semicolon:

$ sudoedit /etc/apt/apt.conf.d/80-local-retries
Acquire::Retries "3";

Check that APT can parse the configuration without starting a package transaction:

$ apt-config dump | grep '^Acquire::Retries'

To undo this example, remove only the fragment you created, then run the dump command again:

$ sudo rm /etc/apt/apt.conf.d/80-local-retries
$ apt-config dump | grep '^Acquire::Retries'

The final command should produce no matching line if there is no other source for that setting. Do not edit /etc/apt/apt.conf just to add one local preference when a numbered fragment gives you a smaller rollback target. Treat automatic confirmation, hooks, proxy commands and repository locations as security-sensitive: audit them before use and never paste untrusted configuration into a root-owned file.

7. Keep common failure modes separate

• "Unable to locate package": check the spelling, repository components, architecture, and whether apt update completed successfully.
• Held or conflicting packages: inspect the proposed changes and package policy. Do not force a removal merely to make the command finish.
• Interrupted package configuration: capture the error first, then use the package manager's documented recovery for the specific failure. Avoid deleting package database files or lock files.
• Lock errors: another package operation may be running. Wait for it to finish and inspect the owning process before taking action; never remove a lock file as a shortcut.
• Unexpected removals: cancel the prompt, check the configured sources and preferences, and compare the plan with apt-cache policy PACKAGE_NAME.

When an operation fails, save the complete terminal output and the exit status immediately with printf '%s\n' "$?". Do not run a second command first: it replaces the status you are trying to diagnose.