12.4 Basic Package Interaction with apt

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

12.4 Basic Package Interaction with apt

Key Takeaways Explain This Topic AI

apt update refreshes package indexes; apt upgrade installs available upgrades and may add new dependency packages but never removes one (apt-get upgrade will not even add); apt full-upgrade may additionally remove packages to satisfy dependencies

On a rolling release like Kali, apt full-upgrade (the apt-get dist-upgrade equivalent) is the safe default because library transitions regularly require adding or removing packages

apt remove uninstalls a package but keeps its system-wide configuration files; apt purge deletes those configuration files too

apt autoremove deletes orphaned dependencies — packages that were pulled in automatically and are no longer required by anything

Use apt search and apt show to query remote packages, apt list --installed and --upgradable for inventory, and dpkg -l (or dpkg -S / dpkg -L) for low-level local queries

Last updated: July 2026

update vs upgrade vs full-upgrade

The three commands form a pipeline, and confusing them is the single most common APT exam error:

apt update — refreshes the local package indexes from your repositories. Installs nothing. (See section 12.2.)

apt upgrade — installs newer versions of packages already installed, and may pull in brand-new packages when a dependency requires it, but with a hard rule: it will never remove an installed package . If completing an upgrade would mean dropping something, apt upgrade holds it back and reports 'The following packages have been kept back'. (Note the front-end difference the exam likes: apt-get upgrade is stricter still — it refuses to install any package that was not already installed.)

apt full-upgrade (the apt command's name for apt-get dist-upgrade ) — upgrades the system and is allowed to install new dependencies and remove conflicting or obsolete packages to complete the transaction. It shows you the full plan, including removals, before asking for confirmation.

Why full-upgrade is the default on Kali

On a fixed-release distribution, plain apt upgrade is often enough because dependencies barely move. Kali is rolling : libraries like Python, OpenSSL, and glibc transition continuously, and a new tool version frequently depends on a library that does not exist on your system yet, or conflicts with a package that must go. If you only ever run apt upgrade , kept-back packages pile up and the system drifts into a partially updated state. The Kali documentation's recommended routine is therefore: sudo apt update && sudo apt full-upgrade -y

Read the removal list before confirming — full-upgrade is safe, not blind, and a plan that wants to remove hundreds of packages usually means a broken mirror or a mid-transition repository, in which case you wait a few hours rather than accept.

install, remove, purge, autoremove

apt install nmap — resolves dependencies, downloads, and installs. apt install nmap --reinstall refreshes an existing install; apt install ./local.deb installs a local file with dependency resolution (unlike dpkg -i ).

apt remove nmap — uninstalls the package but leaves system-wide configuration files (under /etc) in place, so reinstalling later restores your settings. dpkg shows such packages in rc state.

apt purge nmap (or apt remove --purge nmap ) — also deletes those configuration files. Use purge when a corrupted config is the reason you are reinstalling.

apt autoremove — removes orphaned dependencies : packages that were installed automatically to satisfy a Depends that no longer exists. Over months of rolling upgrades this reclaims significant disk. apt autoremove --purge cleans their config files too.

A nuance worth knowing: the distinction between remove and purge applies to system-wide configuration only. Configuration inside a user's home directory (dotfiles) is never touched by either command — removing Burp Suite does not delete ~/.java settings.

Discovery and Inventory Commands

Before and after installing, you need to query the package world. Split the toolbox into APT-side (knows about repositories) and dpkg-side (knows about the local system):

• APT-side queries
• apt search metasploit — full-text search over package names and descriptions in the downloaded indexes

apt show nmap — prints the control-file metadata: version, dependencies, installed size, homepage, description. Works whether or not the package is installed; apt show -a nmap shows all available versions

• apt list --installed — lists everything installed (warns about unstable CLI, so use dpkg in scripts)
• apt list --upgradable — run after apt update to preview what an upgrade would touch, without changing anything
• dpkg-side queries

dpkg -l — lists every package dpkg knows about with a three-character state code (desired action / current status / error flag; the error column is blank in healthy output). The classic pattern is: dpkg -l | grep '^ii'

dpkg -l | grep nmap

The first character is the desired action (i = install), the second the current status (i = installed). You will also see rc — removed but config files remain — which is your reminder that remove is not purge.

dpkg -L nmap — lists the files a package installed

dpkg -S /usr/bin/nmap — reverse lookup: which package owns this file? Invaluable on an unfamiliar engagement machine when you find a binary and want to know what put it there

• dpkg -s nmap — status and metadata for an installed package, from /var/lib/dpkg/status
• A worked upgrade session
• A typical maintenance cycle on Kali looks like this: sudo apt update
• apt list --upgradable
• sudo apt full-upgrade
• sudo apt autoremove

Note which commands need root: anything that modifies the system (update writing to /var/lib/apt/lists, upgrade, install, remove) needs sudo; pure queries (search, show, list, dpkg -l/-L/-S) run fine as the unprivileged kali user. The exam also likes to test that apt full-upgrade and apt-get dist-upgrade are two names for the same behavior — if a question describes 'an upgrade that may remove obsolete packages and install new dependencies', both answers describe one operation.

Finally, remember the ecosystem boundary these commands share: everything above operates only on packages from repositories in your sources.list. A tool you installed from a git clone, a pip package, or a downloaded AppImage is invisible to apt and dpkg — another reason exam answers that propose 'apt remove' to clean up a manually compiled tool are wrong.

Safer experimentation: simulate, hold, download

Three more tools round out the operational kit. Append --simulate (short form -s) to any install, upgrade, or remove command to see the complete plan without changing a single byte — the ideal way to inspect what full-upgrade intends to remove before you commit. apt-mark hold packagename pins an installed package so upgrades skip it ( apt-mark showhold lists held packages); this is the standard workaround when a regression forces you to freeze a mission-critical tool until a fix lands. And apt download packagename fetches the .deb into your current directory without installing it, which is handy for offline inspection with dpkg-deb --info and dpkg-deb --contents . All three operate inside the same signed-repository model as every other command in this chapter. Two more belong in the same kit. apt clean empties /var/cache/apt/archives/ of every downloaded .deb, while apt autoclean removes only the cached .debs that are no longer downloadable from the mirror — the safer routine on a rolling system that upgrades constantly. And when a transaction is interrupted and dpkg leaves packages unpacked but unconfigured, dpkg --configure -a re-runs the pending configuration step for all of them; it is the low-level counterpart to apt --fix-broken install (the apt-get -f install you will see in older output).