APT is the package-management tool used by Debian, Ubuntu, and other Debian-based Linux distributions. It installs, updates, upgrades, and removes software while resolving package dependencies.

APT usually downloads packages from repositories: servers that publish package files and signed metadata. This guide explains the essential APT commands, where repository settings live, how package signatures work, and when to install a local .deb file.

Common APT commands

$ sudo apt update           # Refresh the local package index
$ sudo apt upgrade          # Upgrade installed packages
$ sudo apt install nginx    # Install nginx
$ sudo apt remove nano      # Remove nano

apt update refreshes the local index of packages available from configured sources; it does not install updates. apt upgrade installs available upgrades for installed packages. Run apt update before upgrading so APT has current repository metadata.

APT repository

An APT repository is a package archive containing .deb packages and metadata that describes available versions, dependencies, and file checksums. APT uses its configured repositories to find packages and determine what can be installed or upgraded.

Common sources include:

• Official distribution archives, such as Ubuntu main, universe, restricted, and multiverse components.
• Distribution security and updates archives.
• Third-party vendor repositories.
• Local or private mirrors used by organizations.

Where are APT repositories configured?

APT reads repository sources from /etc/apt/sources.list and files in /etc/apt/sources.list.d/. The format can vary by distribution and release.

Many older systems use one-line entries in files ending in .list, such as:

deb https://archive.ubuntu.com/ubuntu jammy main universe

The fields are the package type (deb for binary packages, deb-src for source packages), repository URL, suite or release codename, and components.

Current Ubuntu releases commonly use deb822 files ending in .sources. A source entry looks like this:

Types: deb
URIs: https://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates
Components: main universe
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Third-party repositories are commonly kept in separate files under /etc/apt/sources.list.d/, which makes them easier to inspect and manage. Check your distribution’s documentation before editing these files; the exact format and default locations depend on the release.

How APT verifies repositories

APT verifies signed repository metadata and checks that downloaded package files match the checksums in that metadata. This helps detect tampering and confirms that the repository metadata was signed by a key APT trusts.

When adding a third-party repository, follow the vendor’s current installation instructions. Prefer a repository-specific keyring and reference it using Signed-By in that repository’s source entry. This limits which repository can use that key. Avoid legacy instructions that add vendor keys to a global trust store or use the deprecated apt-key command.

For example, a one-line .list entry can scope a key like this:

deb [signed-by=/usr/share/keyrings/vendor-archive-keyring.gpg] https://packages.example.org/debian stable main

The URL, distribution suite, components, and keyring path are examples only. Use the values supplied by the repository maintainer and verify the signing-key fingerprint through a trusted channel.

Be careful with install scripts

A command such as:

$ curl -fsSL https://example.org/install.sh | bash

downloads a script and immediately runs it. If the script uses sudo, it may make system-wide changes, such as adding a repository, installing a signing key, refreshing package metadata, or installing software. You cannot inspect the script before it starts running.

A safer approach is to download the script, inspect it, verify that it comes from the project’s genuine site or repository, and then run it only if you understand and trust what it does:

$ curl -fsSL https://example.org/install.sh -o install.sh
$ less install.sh
$ bash install.sh

Replace the example URL with the project’s official script location. Inspect the full script and any scripts or files it downloads. If a project provides documented package-repository setup steps, follow those directly instead of running an opaque installer.

What is a .deb file?

A .deb file is a Debian binary package. It contains package metadata, files to install, and sometimes maintainer scripts that run during installation or removal. Metadata includes the package name, version, architecture, dependencies, maintainer, and description.

For a local package file, use APT when you want dependency resolution:

$ sudo apt install ./package-name.deb

The ./ tells APT to use a file in the current directory. APT can install the package’s dependencies from configured repositories, if they are available.

You can also install a package with dpkg:

$ sudo dpkg -i package-name.deb

dpkg installs the specified package but does not fetch missing dependencies. If that leaves dependencies unconfigured, APT can attempt to resolve them:

$ sudo apt --fix-broken install

Only install .deb files from sources you trust. A package may run maintainer scripts with administrative privileges during installation.

Inspect package metadata

To inspect the metadata in a local package file without installing it, use:

$ dpkg-deb --info package-name.deb

To list the files it contains:

$ dpkg-deb --contents package-name.deb

Package metadata is how APT and dpkg understand what a package provides and what it needs. Dependency information helps APT plan installations and upgrades, while package scripts may perform setup tasks during installation.

Documentation references

• Ubuntu: Install and manage packages
• Ubuntu: Third-party repository usage
• Ubuntu: Package archive and APT sources
• APT sources.list manual
• Debian: APT command-line interface

APT makes software management on Debian-based systems straightforward by working with repositories, package metadata, and dependencies. Keep repository sources current, use scoped signing keys for third-party archives, and inspect scripts or local packages before running them with administrative privileges.

We hope this was helpful.
Keep learning. Keep exploring. Stay secure.