Installing and Removing Packages

The previous lesson established the package concept and dependency resolution. This lesson descends to everyday operations.

Command names vary by package manager family; this course does not teach a specific tool’s syntax. What is taught is which operation does what and in what order — this knowledge travels, command names do not. To find their counterparts on a given system, the manual pages from the help resources lesson are enough.

Operation Classes

Whatever its family, every package manager has a counterpart for these operations:

Operation	What it does
Index update	Refreshes the local copy of the repositories’ package list
Search	Searches for a package by name and description
Show	Prints a package’s metadata
Install	Installs a package and its dependencies
Remove	Deletes the package’s files, leaves configuration
Purge	Also deletes configuration files
Autoremove	Removes packages installed as dependencies that are no longer needed
Upgrade	Moves installed packages to their new versions
File list	Lists the files a package installed
Ownership query	Finds which package a file belongs to
Verify	Compares installed files against the recorded checksums

The first row is the operation that should come first in sequence. The local index is a copy of the repository’s contents and can go stale. An installation done with a stale index tries to download a version no longer in the repository and fails. This is why installation follows an index update.

The last row is where the checksums covered in the previous lesson get used: if an installed file’s content differs from the recorded one, it was either edited by hand or has been corrupted. This is one of the first questions to ask in a fault investigation.

Reading the Action List

Install and remove commands list what will happen before acting and ask for confirmation. The list has three sections: what will be installed, what will be removed, what will be upgraded.

Three points need checking before confirming.

Is the removal list empty? If installing a package requires removing others, a conflicting dependency exists. If the list contains unexpected names, the operation should be canceled.

Is the number of pulled-in dependencies at the expected level? A small tool pulling in hundreds of packages can mean the wrong package was chosen, or that a far too broad meta-package was requested.

Are the packages coming from the expected repository? If more than one repository is configured, the same package can come from different sources. Source is the subject of the next lesson.

Installation operations require root privilege; they write to system directories and run install scripts with privilege. The principle from the privilege escalation lesson applies directly here: granting package-installation privilege is close to granting root privilege itself, because install scripts run as root.

Removal and Purging

The difference between the two removal operations lies in the configuration files.

Removal deletes the files the package brought but leaves the configuration under /etc. The reasoning: configuration files have been edited by the administrator, and that effort is expected to be preserved if the package is removed and reinstalled.

Purging deletes the configuration too. This is chosen when the package is certain never to be used again and a clean state is wanted.

Neither deletes user data. Settings in home directories and data under /var are not in the package manager’s record; the package did not create them, and it does not delete them either. If a service’s data should also go after it is removed, that is a separate, deliberate step.

Packages installed as dependencies are marked separately. When a package is removed, only the dependencies pulled in for it remain on the system, but they are marked “no longer needed”; the autoremove operation collects them. Without this distinction, the system would fill over time with packages nothing uses.

Upgrading

Upgrading has two scopes, and confusing them is risky.

Single-package upgrade renews only the named package. If its dependencies also require a new version, they are upgraded too.

System upgrade moves every installed package to the repository’s current versions. Because the repository is published as a consistent whole, this is the recommended path.

The dangerous zone in between is a partial upgrade: when some packages are left new and some old, the versions of interdependent libraries can stop matching. Repository maintainers test packages together; a set upgraded separately is an untested combination.

If a version needs to be deliberately held back, package managers offer a pinning mechanism for this: a package or version is flagged and left out of upgrades. Pinning is knowingly taking on the risk of a partial upgrade, and the reason should be documented.

Downgrading is generally not supported. Install scripts are written to run forward; going back to an old version after an upgrade that converted a data format can leave the data unreadable.

Outside the Package Manager

Not all software is in a repository. The layout standard defines an area set aside for this case: /usr/local is where locally installed software goes, untouched by the package manager. The user-level counterpart of the same distinction is a local directory under the home directory, and it requires no root privilege.

$ mkdir -p ~/.local/bin
$ chmod 755 ~/.local/bin/project-backup
$ cat ~/.local/bin/project-backup
#!/bin/sh
# Archives the project tree with a dated name.
tar -czf "$HOME/project/archive/project-$(date +%Y%m%d).tar.gz" -C "$HOME" project/data project/scripts project/docs

This directory is added to the search list by the configuration read at login:

$ echo "$PATH"
/home/student/project/scripts:/home/student/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ command -v project-backup
/home/student/.local/bin/project-backup

The tool can now be called from anywhere:

$ project-backup
$ ls -l project/archive
total 84
-rw-r--r-- 1 student student 11665 Jul 26 19:35 project-20260726.tar.gz
-rw-r--r-- 1 student project 51200 Jul 26 19:10 data.tar
-rw-r--r-- 1 student project 11330 Jul 26 19:10 data.tar.gz
-rw-r--r-- 1 student project  4416 Jul 26 19:10 data.tar.xz

The command from the archiving lesson has turned into a tool that runs with a dated name in a single call.

This approach’s limit is the database discussion from the previous lesson. For a single-file tool, removal is one rm command. For software that spreads dozens of files across six directories, removal cannot be done reliably because no record exists of which file belongs to what. That is exactly the problem the package manager solves.

The criterion is this: single-file, dependency-free tools can go into the local directory; dependent software that spreads across the system should go through the package manager. For the middle ground, a layout that confines the software to its own directory and links it to the search list with a single link is preferred; removal then reduces to deleting that directory.

Summary

• Package managers offer the same operation classes under different command names; what travels is the operation knowledge, not the command name.
• Installation happens after the local package index is updated; a stale index tries to download versions no longer available.
• The action list is checked for what will be removed, how many dependencies are pulled in, and where the packages come from.
• Removal leaves configuration, purging deletes it too; neither touches user data.
• A partial upgrade produces an untested combination of versions; pinning is knowingly taking on that risk.
• Installation outside the package manager suits single-file, dependency-free tools; it is not reliable for software that spreads across the system, since no removal record exists.

Next Step

Where packages come from was called the “repository” in this lesson but never defined. A repository is not just a file server: an index file, that file’s signature, and package checksums together build a chain of trust. The next lesson opens that chain and shows why adding a new repository to the system is a trust decision.