---
title: 'Installing and Removing Packages'
source: 'https://academia.sh/en/courses/introduction-to-linux/installing-and-removing-packages'
course: 'Introduction to Linux'
language: en
updated: '2026-08-17T18:09:56+00:00'
license: 'CC BY-SA 4.0'
---

# Installing and Removing Packages

The operation classes common to package manager families, reading the action list, the difference between removal and purging, and installation areas outside the package manager.

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.