Managing Packages, Dependencies, and Configuration Files

Hello. In the previous lesson, you established two controls that must precede package changes: repository trust through scoped signing keys, and package selection through APT policy and priorities. This lesson puts that information into operation. Before installing or upgrading anything, you will inspect the candidate version and simulate the transaction; then you will know what APT intends to add, upgrade, retain, or remove.

For LFCS-style administration, the command is rarely the difficult part. The important skill is predicting its consequences: dependency changes, automatically installed packages, preserved configuration, and the difference between removing a program and purging its package state.

---

The package transaction model

APT manages transactions, not isolated files. When you request a package, APT considers:

1. The candidate version selected by configured repositories and preferences.
2. Its declared dependencies and conflicts.
3. Whether dependencies are marked as manually or automatically installed.
4. The currently installed package set.
5. Holds that prevent ordinary automatic changes.

The safe operational pattern is:

Inspect candidate and relationships.
Simulate the requested transaction.
Read every proposed addition, upgrade, and removal.
Perform the transaction only when the result matches the intended change.
Verify the resulting state.

Use apt for normal interactive administration and apt-get when you want stable, script-oriented behavior or a clean simulation. Both use the same underlying APT data and resolver.

The following video gives a compact visual walkthrough of installation, removal, and upgrade behavior.

Inspect before acting

Suppose you plan to install tmux in a disposable Ubuntu VM. First refresh metadata if it may be stale, such as after changing sources or after a substantial amount of time:

sudo apt update

Remember: apt update downloads repository metadata. It does not install or upgrade packages.

Then inspect the candidate:

apt-cache policy tmux

Look for:

• Installed: the version currently installed, if any.
• Candidate: the version APT would select now.
• The repository and priority associated with each available version.

Inspect direct dependency relationships when you need context:

apt-cache depends tmux

This is useful background, but it is not a final transaction plan. The installed package set affects what APT actually needs to add or remove. A simulation is the authoritative prediction:

apt-get -s install tmux

The -s option means simulate. No packages are downloaded, unpacked, configured, or removed.

Read the output as a change plan:

Transaction output	Meaning
NEW packages will be installed	Requested package plus dependencies not currently present
packages will be upgraded	Installed packages moving to selected newer versions
packages will be REMOVED	Packages that conflict or can no longer satisfy dependencies
automatically installed and no longer required	Candidates for later autoremove; not necessarily removed by this command
Recommended packages	Packages APT normally installs by default unless you choose otherwise
Suggested packages	Optional enhancements, not installed by default

Do not approve a transaction merely because the requested package appears in the list. A package installation that unexpectedly proposes removal of a service, a kernel component, or a metapackage deserves investigation before any change is made.

---

Installation, dependencies, and manual intent

When you explicitly request a package, APT normally marks it manually installed. Packages brought in solely to satisfy dependencies are normally marked automatically installed.

Install the package after reviewing the simulation:

sudo apt install tmux

APT resolves required dependencies automatically. On Ubuntu, it also normally installs packages listed as Recommends. To install only required dependencies, use:

sudo apt install --no-install-recommends PACKAGE

This can be appropriate for deliberately minimal servers or containers, but use it only when you understand what functionality a recommended package supplies.

Manual versus automatic is not cosmetic

APT’s manual/automatic marker records why a package is present. This affects autoremove.

View the categories:

apt-mark showmanual
apt-mark showauto

If you began using a package that was originally installed only as a dependency, mark it manual before removing the original package:

sudo apt-mark manual PACKAGE

Conversely, marking a package automatic permits APT to consider it for removal when no manually installed package needs it:

sudo apt-mark auto PACKAGE

Do not casually mark packages automatic on a production system. A future autoremove may then correctly, but unexpectedly, identify them as unused.

A typical safe cleanup sequence is:

apt-get -s autoremove
sudo apt autoremove

The simulation matters because autoremove evaluates the entire installed dependency graph, not merely the package you removed most recently.

---

Upgrading selected packages or the system

There are three common upgrade scopes.

Upgrade one package

If a package is installed and a newer candidate exists, this command installs the candidate version:

sudo apt install PACKAGE

For an explicitly upgrade-only request, use:

sudo apt install --only-upgrade PACKAGE

The second form avoids accidentally installing a package that was absent. In either case, inspect the candidate version first:

apt-cache policy PACKAGE
apt-get -s install --only-upgrade PACKAGE

A package name alone means “install the current candidate,” not “install the latest version from a repository I happen to prefer.” The candidate is still determined by your repository configuration and APT preferences from the previous lesson.

Upgrade ordinary eligible updates

To update packages system-wide without removing installed packages:

sudo apt update
apt list --upgradable
apt-get -s upgrade
sudo apt upgrade

apt upgrade applies updates that can be resolved without removing already installed packages. It may leave some packages unchanged when their upgrade would require more disruptive dependency changes.

Resolve dependency-changing updates deliberately

For a system-wide update where APT may need to change dependency relationships, use a simulation first:

apt-get -s dist-upgrade

With the apt interface, the comparable command is:

apt -s full-upgrade

A full upgrade can install additional dependency packages and can remove packages when necessary to reach a consistent set of selected versions. This is sometimes required, particularly around transitions involving kernels, metapackages, or replaced packages. It is also why it must be reviewed rather than run blindly.

Avoid adding -y to broad upgrade or removal commands during certification practice. The confirmation prompt is an opportunity to catch an unintended transaction.

---

Holds: temporary protection against ordinary APT changes

A package hold tells APT not to automatically install, upgrade, or remove that package. Use a hold when a package must remain at its current installed state for a documented reason, such as a known regression in a newer version or a short maintenance-window constraint.

sudo apt-mark hold PACKAGE
apt-mark showhold

Remove the hold when the reason has been addressed:

sudo apt-mark unhold PACKAGE

A hold does not alter the candidate shown by apt-cache policy. A newer version may still be available and selected as the candidate, while the installed package remains unchanged because of the hold. That distinction is useful in troubleshooting: repository policy determines what version is preferred; a hold determines whether APT may normally change the installed package.

A hold is not a long-term security strategy. A held package does not receive ordinary upgrades, including security fixes. Record why it was held, monitor its candidate version, and unhold it as soon as a safe replacement or update plan exists.

---

Remove versus purge: preserving or deleting package configuration

The most frequently examined distinction is this:

• remove removes packaged program files but preserves registered package configuration files.
• purge removes packaged program files and registered package configuration files.

For example:

sudo apt remove PACKAGE

After a removal, dpkg can retain the package in the rc state: removed, configuration files remain. This is intentional. Reinstalling later can restore the application while retaining prior configuration.

Check the package state:

dpkg -l PACKAGE

A status beginning with rc commonly indicates that the package itself has been removed but its registered conffiles remain.

To remove the package and its registered configuration files in one operation:

sudo apt purge PACKAGE

This is equivalent in intent to:

sudo apt remove --purge PACKAGE

If the package is already removed and only configuration residue remains, apt purge PACKAGE is still the appropriate cleanup command.

What configuration does purge actually remove?

A conffile is a configuration file explicitly designated by the package maintainer for special handling by dpkg. Many conffiles are under /etc, but not every file under /etc is necessarily a conffile.

Inspect a package’s registered conffiles with:

dpkg-query -W -f='${Conffiles}\n' PACKAGE

During an upgrade, dpkg protects locally modified conffiles. If both you and the package maintainer changed the same conffile, dpkg prompts for a decision rather than silently overwriting local administration.

Purging is not a universal data-erasure operation. It may not remove:

• Files created manually outside package control.
• Application data under locations such as /var/lib.
• Logs under /var/log.
• Per-user settings in home directories.
• Data on mounted volumes or network storage.

Package maintainer scripts influence some cleanup behavior, so inspect application-specific documentation before purging a stateful service such as a database, monitoring server, or identity service. Back up relevant configuration and application data first.

---

A controlled lab workflow

Use a harmless, nonessential package in a disposable VM. tmux is a reasonable example if it is not already part of your environment.

1. Predict and install

sudo apt update
apt-cache policy tmux
apt-cache depends tmux
apt-get -s install tmux
sudo apt install tmux

Confirm its installed state:

dpkg -l tmux
apt-mark showmanual | grep -x tmux

2. Practice a hold without forcing an update

sudo apt-mark hold tmux
apt-mark showhold
apt-cache policy tmux
sudo apt-mark unhold tmux

The candidate may be the same as the installed version in a fully updated lab. That is fine: this exercise verifies the administrative state change, not the presence of an available update.

3. Predict removal and cleanup separately

apt-get -s remove tmux
sudo apt remove tmux
dpkg -l tmux
apt-get -s autoremove

The removal simulation shows what must be removed to preserve dependency correctness. The autoremove simulation shows packages that are now automatic and no longer needed. These are distinct decisions.

4. Purge remaining package configuration

sudo apt purge tmux
dpkg -l tmux

For tmux, there may be little or no system conffile residue. The commands still demonstrate the state distinction. Use a package with registered conffiles only in a disposable environment and only after inspecting its dpkg-query conffile list.

---

Exam-time decision method

Before changing packages, use this compact checklist:

Intended action	Inspect first	Simulate	Verify afterward
Install	apt-cache policy PACKAGE	apt-get -s install PACKAGE	dpkg -l PACKAGE
Upgrade one package	apt-cache policy PACKAGE	apt-get -s install --only-upgrade PACKAGE	Installed version and service health
Upgrade system	apt list --upgradable	apt-get -s upgrade	Remaining upgradable packages
Hold	Installed and candidate versions	Usually not necessary for state change	apt-mark showhold
Remove	Reverse impact in simulation	apt-get -s remove PACKAGE	dpkg -l PACKAGE
Autoremove	Automatic package set	apt-get -s autoremove	Review removed package list
Purge	Registered conffiles and application data locations	apt-get -s purge PACKAGE	No rc package residue

The main takeaway is that APT does not simply “install software.” It resolves the system’s package graph according to repository policy, dependency declarations, manual/automatic markers, and holds. apt-get -s gives you the chance to evaluate that resolution before the system changes.

Next, you will validate package provenance and integrity by connecting APT policy information with package checksums and installed-file verification.