Linux · Lesson 06
Packages, Repositories & Software Review
Inventory Linux software, understand package origins and dependencies, review repositories, plan updates carefully, and remove unnecessary software without breaking required services.
Package management is a security tool and an availability risk. The strongest workflow starts with inventory and dependency reasoning, then makes only the software changes supported by the scenario and verifies the result.
Lesson Snapshot
Learning objectives
Understand software before you remove or upgrade it
Explain how APT, repositories, package metadata, dependencies, and installed software fit together on Ubuntu and Linux Mint.
Inventory installed packages and software sources before removing or updating anything.
Distinguish required, optional, unnecessary, suspicious, and unknown software using evidence rather than names alone.
Review package origin, version, repository configuration, and update state without breaking required applications or services.
Understand why package removal, repository edits, and full upgrades can have dependency and availability consequences.
Verify system functionality after software changes and preserve evidence when a package may matter to forensics.
Core idea
Software inventory is dependency mapping
An installed package can provide a command, library, service, or dependency used elsewhere. Before removal, determine what the package does, who depends on it, and whether the scenario requires that function.
Availability risk
Package actions can change more than one thing
Removal, purge, autoremove, and broad upgrades can affect dependencies, services, configuration, and reboot requirements. Preview the action and protect required functionality.
Package-management fundamentals
Six concepts behind software review
Package
A package is a managed software unit that can contain programs, libraries, service files, configuration templates, documentation, and metadata.
Repository
A repository is a configured software source from which the package manager can learn about and retrieve packages and updates.
Dependency
A package may rely on other packages. Removing one package can therefore affect several applications or services.
Installed state
A package being installed does not prove that its service is running, that a user launches it, or that the software is required.
Origin
Package metadata can help show which repository or source a package came from, which is useful when evaluating unfamiliar software.
Update posture
Security updates matter, but upgrades should be planned around system role, required services, restart risk, and scenario requirements.
Tool map
Know which package tool answers which question
aptHigh-level package-management interface for searching, installing, removing, and updating packages.
apt-cacheQueries package metadata, candidates, and repository policy without changing installed software.
dpkgLower-level Debian package database tool useful for listing installed packages and identifying package ownership of files.
apt-markShows manually and automatically installed packages and can help with dependency reasoning.
snapManages Snap packages if the system uses Snap.
flatpakManages Flatpak applications if Flatpak is installed and in use.
Inspection first
Build a software inventory before changing it
apt list --installed 2>/dev/nullList packages that APT reports as installed.
dpkg -lShow Debian package database status for installed and previously known packages.
apt-cache policy package-nameShow installed version, candidate version, and configured repository sources for one package.
apt show package-nameDisplay package metadata such as description, dependencies, source, size, and version.
dpkg -S /path/to/fileIdentify which Debian package owns a specific installed file when known to the package database.
apt-mark showmanualList packages marked as manually installed.
apt-mark showautoList packages marked as automatically installed as dependencies.
apt list --upgradable 2>/dev/nullShow packages with available upgrades according to the current package metadata.
grep -R --no-filename -h '^[^#].*deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/nullReview active traditional APT repository entries without editing them.
find /etc/apt/sources.list.d -maxdepth 1 -type f -print 2>/dev/nullList repository source files for inspection.
snap list 2>/dev/nullList installed Snap packages when Snap is available.
flatpak list 2>/dev/nullList installed Flatpak applications and runtimes when Flatpak is available.
Package inventory is not complete software inventory
Check Snap, Flatpak, /opt, /usr/local, user home directories, startup entries, services, and running processes when you need a fuller picture of installed software.
Software classification
Required, optional, unnecessary, suspicious, or unknown
Required
Evidence
Named in the scenario, supports a required service, required by another known application, or clearly part of the intended system role.
Response
Preserve it. Review its configuration and update state rather than removing it.
Optional
Evidence
Legitimate software that is not clearly required but also not harmful or problematic.
Response
Leave it alone unless the scenario or policy gives a reason to remove it.
Unnecessary
Evidence
Legitimate software that is explicitly prohibited, clearly outside the intended role, or not needed and creates avoidable exposure.
Response
Confirm dependencies and removal impact before uninstalling.
Suspicious
Evidence
Unexpected origin, unusual package behavior, unexplained persistence, strange service relationship, or evidence connecting it to a security issue.
Response
Preserve evidence and investigate before removal.
Unknown
Evidence
Purpose, origin, dependency, or scenario relationship is not yet clear.
Response
Research locally using package metadata, file ownership, services, processes, and repository configuration.
Repository review
Software trust begins with configured sources
Main sources
/etc/apt/sources.listInspect active entries, distribution codename, repository components, and whether the source matches the intended system.
Additional sources
/etc/apt/sources.list.d/Review third-party repository files and understand which installed software depends on them.
Keyrings
/etc/apt/keyrings/On many modern systems, repository signing keys may be stored here or referenced from source definitions.
Deb822 sources
/etc/apt/sources.list.d/*.sourcesNewer systems may use Deb822-style .sources files instead of only traditional .list entries.
APT history
/var/log/apt/Package history can show installs, removals, and upgrades that may matter to troubleshooting or forensics.
Ubuntu and Mint can differ here
Linux Mint commonly uses Ubuntu package foundations plus Mint repositories and its own update tooling. Review the actual image rather than assuming one repository layout fits both systems.
Evidence-based software reasoning
Replace package-name guesses with dependency analysis
An unfamiliar package is installed
Weak response
Remove it because the name is unfamiliar.
Better reasoning
Use apt show, apt-cache policy, dpkg -L, service/process checks, and scenario context to determine purpose and dependencies first.
A package has an update available
Weak response
Run a full upgrade immediately.
Better reasoning
Review required services, restart risk, dependency changes, available time, and scenario expectations before broad upgrading.
A third-party repository exists
Weak response
Delete the repository file.
Better reasoning
Identify which software depends on the source, confirm legitimacy, and preserve evidence before changing repository configuration.
A package is marked auto-installed
Weak response
Autoremove everything.
Better reasoning
Understand what packages depend on it and inspect the proposed autoremove set before accepting changes.
A server package exists on a desktop image
Weak response
Server software does not belong on a desktop.
Better reasoning
Determine whether the scenario requires the service, whether it is active, which port it exposes, and whether it supports a required application.
A package was installed recently
Weak response
Recent means malicious.
Better reasoning
Correlate APT history, user activity, service creation, file timestamps, and scenario changes before drawing a conclusion.
Update workflow
Plan software updates around required functionality
Identify the system role
Know which applications and services must remain available before changing software.
Refresh metadata deliberately
Understand that apt update refreshes package metadata; it does not itself install package upgrades.
Review available upgrades
Inspect which packages would change and whether critical services, kernels, libraries, or desktop components are involved.
Plan restart impact
Some package updates may require service restarts or a reboot to fully apply.
Make the smallest justified change
Apply scenario-supported updates or package changes without bundling unrelated removals or repository edits.
Verify required functions
Test applications, services, networking, remote access, and user workflows after the change.
Controlled package actions
Preview high-impact changes before confirming them
Goal
Refresh package metadata
Example
sudo apt updateCaution
This contacts configured repositories and refreshes metadata. Review repository configuration first if software sources are under investigation.
Goal
Upgrade one package
Example
sudo apt install --only-upgrade package-nameCaution
Review dependencies and service impact before upgrading a package tied to a required application.
Goal
Remove one package
Example
sudo apt remove package-nameCaution
Inspect the proposed removal set before confirming. Required dependencies or services may be affected.
Goal
Remove package and configuration
Example
sudo apt purge package-nameCaution
Purge can remove package-managed configuration files. Preserve evidence or custom configuration first when relevant.
Goal
Simulate removal
Example
apt -s remove package-nameCaution
Simulation helps preview package actions without applying them. Use it before high-impact removals.
Goal
Preview autoremove
Example
sudo apt -s autoremoveCaution
Never assume every automatically installed package is safe to remove. Review the proposed set.
Complete software inventory
Packages are only one delivery method
Debian/APT packages
Use apt, apt-cache, dpkg, and repository policy to understand package origin and dependency relationships.
Snap
Use snap list and snap info when Snap is present. A package may be legitimate even though it is not visible through dpkg.
Flatpak
Use flatpak list and application metadata when Flatpak is present.
Manual installs
Check /opt, /usr/local, user home directories, application launchers, services, and startup entries for software installed outside package managers.
Scripts
Administrative or user scripts may provide important functionality without appearing as installed packages.
Containers or app bundles
Some software may run through containers, AppImages, or other delivery methods. Package inventory alone is not a complete software inventory.
High-risk shortcuts
Package actions that deserve extra caution
sudo apt upgrade -y without reviewAutomatically accepting a broad upgrade can restart services, change dependencies, or create troubleshooting work without understanding the impact.
sudo apt autoremove -yAutomatic removal can uninstall dependencies that still matter to the image or required applications.
Removing every server packageA desktop image can still legitimately provide required network or application services.
Deleting third-party repositories immediatelyThe source may support required software, and the repository definition itself may be useful evidence.
Purging before preserving configurationPackage-managed configuration and logs may be lost or changed before you document them.
Treating package manager output as the whole software inventoryManually installed programs, scripts, Snap, Flatpak, AppImages, and user software may not appear in the same inventory.
Evidence sources
Preserve software history before cleanup
APT history
less /var/log/apt/history.logShows recorded package install, upgrade, and removal actions where retained.
dpkg log
less /var/log/dpkg.logShows lower-level package status changes where the log is retained.
Package metadata
apt show package-nameDescription, version, dependencies, source information, and other metadata.
Repository policy
apt-cache policy package-nameInstalled version, candidate version, and configured source priorities.
File ownership
dpkg -S /path/to/fileIdentifies the package that owns a known file when recorded in the package database.
Service relationship
systemctl status service-nameShows whether installed software is tied to an active service and provides recent runtime context.
Verification
Confirm software and mission state
Package state
Re-run apt or dpkg inventory and confirm the intended package is installed, upgraded, or removed.
Dependency state
Confirm required dependencies remain installed and no unexpected packages were removed.
Service
Verify required services still start and run after package changes.
Application
Test the real user-facing or client-facing application behavior.
Repository
Confirm software sources remain correct and package metadata refresh succeeds when required.
Evidence
Confirm package logs, configuration, and relevant metadata were preserved before destructive changes.
Package success is application success
The package manager completing successfully does not prove the mission still works. Test the required service or application afterward.
Defensive lab
Review a fictional Linux software inventory
Read the fictional scenario: an internal web application and SSH are required; a media-sharing application is prohibited; package logs must be preserved.
Inventory installed APT packages, Snap packages, Flatpak applications, and obvious manually installed software without changing anything.
Use apt-cache policy and apt show on the unfamiliar packages to identify origin, version, description, and dependencies.
Correlate package names with running services, listening ports, files under /opt or /usr/local, and the scenario.
Classify the prohibited media-sharing software as Unnecessary only after confirming it is not required by another scenario function.
Use a simulated removal first and preserve relevant configuration or package-history evidence before uninstalling.
Verify the internal web application, SSH, package manager state, and repository configuration after the change.
Lesson checklist
Before moving on
I understand the difference between a package, repository, dependency, and installed service.
I can inventory installed APT packages before changing them.
I can use apt-cache policy and apt show to investigate package origin and metadata.
I know that manually installed software, Snap, and Flatpak may not appear in the same inventory.
I classify software using scenario role, dependencies, services, and evidence rather than package names alone.
I preview package removals and autoremove actions before confirming them.
I do not run broad upgrades automatically without reviewing impact.
I preserve repository and package-history evidence when software may matter to forensics.
I verify required services and applications after package changes.
I keep Ubuntu and Linux Mint differences in mind when reviewing available software and default repositories.
Reflection
Check your reasoning
Question 1
Why is an installed package not the same thing as a running service?
Question 2
Why should a third-party repository be investigated before deletion?
Question 3
What makes apt -s useful before removing a package?
Question 4
Why can autoremove be risky even when packages are marked automatically installed?
Question 5
How would you investigate a program that does not appear in dpkg output?
Question 6
What should you verify after removing or upgrading software that supports a required service?
Carry this forward
Software review is about role, origin, dependency, and evidence. Inventory first, preview high-impact actions, preserve required services, and prove that the system still performs its mission after the package change.