Use the package manager documented for your distribution. Inspect the package, repository, version, dependencies, and proposed transaction before approving a change. Then verify both the package database and the tool itself.
There is no universal Linux install command. Debian and Ubuntu use APT for
packages from configured Debian-style repositories. Fedora and current
RHEL-family systems use DNF, with current Fedora releases using DNF5. Arch uses
pacman; openSUSE uses Zypper; image-based systems can use a different model.
Do not translate commands by replacing one program name.
Identify the installed system first
Read the operating-system identification file:
cat /etc/os-release
Then inspect possible package tools without changing state:
command -v apt
command -v dnf5
command -v dnf
command -v pacman
command -v zypper
More than one command can exist, especially in containers or compatibility environments. The distribution’s official documentation decides which tool owns the base system.
Record:
Distribution and release:
Package manager and version:
Configured source files:
Managed by institution: yes | no | unknown
Course-required package and version:
Recovery or checkpoint:
Do not add repositories, disable signature checks, or run an update yet.
Separate metadata refresh, package update, and release upgrade
These operations are different:
- refreshing metadata downloads current repository information;
- installing adds or changes selected packages;
- updating packages applies available versions within the current release’s policy; and
- a distribution release upgrade changes the operating-system release.
For Debian and Ubuntu, apt update refreshes metadata; it does not install the
listed upgrades. The Debian
apt manual distinguishes
update, upgrade, and full-upgrade. full-upgrade may remove installed
packages to satisfy the transaction, so it is not a casual substitute for
upgrade.
For Fedora with DNF5, dnf5 check-upgrade lists available updates. The official
DNF5 check-upgrade reference
documents an unusual but intentional result: exit status 100 means updates
are available, while 0 means none are available.
A release upgrade has separate prerequisites and recovery obligations. Use the distribution’s release-upgrade guide, not the ordinary package exercise below.
Inspect one exact package
Choose one instructor-approved, low-risk package. Prefer official distribution repositories unless the course requires another source.
On Debian or Ubuntu:
apt search exact-or-distinctive-name
apt show package-name
apt-cache policy package-name
apt show displays package metadata; apt-cache policy helps identify
candidate and installed versions and their sources. Search results can include
similar names, virtual packages, and packages from multiple suites.
On Fedora with DNF5:
dnf5 search exact-or-distinctive-name
dnf5 info package-name
dnf5 repo list --enabled
Confirm these forms with dnf5 --help and the installed manual. Older supported
RHEL-family systems may provide DNF4 as dnf; its commands and output are
similar in places but not identical.
For another distribution, use its official package-manager guide. Record the exact package identity, repository, candidate version, installed state, download size, installed size, and why the course needs it.
Preview and read the transaction
Package-manager simulation support differs.
APT provides a simulation option:
apt-get --simulate install package-name
Read the proposed new, upgraded, removed, and held packages. A simulation is useful evidence, but local state can change between preview and execution.
DNF normally resolves and presents a transaction summary before asking for confirmation. Read every section. Do not add automatic confirmation flags while learning.
Stop when the transaction:
- removes a desktop, kernel, package manager, or another unexpected package;
- changes repositories or accepts an unknown signing key;
- proposes a distribution release change;
- conflicts with a course-required version;
- requires broad changes immediately before a deadline; or
- differs materially from the preview.
Apply one bounded change
Close affected applications, save work, and record the starting state. On a personal Debian or Ubuntu system:
sudo apt install package-name
On a personal current Fedora system:
sudo dnf5 install package-name
These are distribution-family examples, not permission to alter a managed machine. Read prompts and approve elevation only for the expected package operation. Do not paste repository setup commands or disable package authentication to make an error disappear.
For an update exercise, choose one noncritical package only if the manager and repository support that bounded transaction. Confirm that partial updates are supported by the distribution; Arch, for example, expects full system upgrades and warns against partial upgrades in its official documentation.
Verify package and behavior
Use the package manager to inspect installed state, then use the command’s own version or harmless course workflow:
apt-cache policy package-name
or:
dnf5 info --installed package-name
Open a new shell if command lookup paths changed. Record the actual command path, version, exit status, and one expected behavior.
Transaction history can support diagnosis. DNF5 documents read-only
dnf5 history list and history info.
APT records logs under /var/log/apt/ on typical Debian/Ubuntu systems, subject
to permissions and retention. History is evidence, not guaranteed rollback.
Common mistakes
- Copying an APT command onto Fedora or a DNF command onto Ubuntu.
- Treating metadata refresh as package installation.
- Selecting a package by display name without checking repository and version.
- Approving unexpected removals.
- Adding
-ybefore reading the transaction. - Disabling signature verification.
- Mixing base packages, Snap, Flatpak, language packages, and manual downloads into one unexplained inventory.
- Calling history a complete rollback mechanism.
Do this now
Identify the distribution and package manager. Inspect one approved package and preview or read its proposed transaction. If policy and timing allow, install or update only that package and verify it two ways. Otherwise stop after inspection and record the constraint.
Log what you learned
Record only:
- Result: What did the action produce?
- Evidence: What observation, test, or source supports that result?
- Next action or unresolved question: What should happen next?
Next, learn to inspect Linux processes, services, and logs without changing them.