dependencies

Overview

Software rarely stands alone — most programs rely on other libraries and packages to function. These are dependencies, and package managers exist largely to handle them automatically. This lesson explains dependencies and the issues they raise.

Learning objectives

• Define a dependency and why it exists.
• Explain how package managers resolve dependencies.
• Recognize dependency-related problems and risks.

Core concept

A dependency is another package that a given package requires in order to work — typically shared libraries or supporting tools. Rather than each program bundling its own copy of every library, Linux shares them, so packages declare what they depend on. The package manager performs dependency resolution: when you install a package, it automatically installs everything that package needs.

How it works

Each package's metadata lists its dependencies (and their acceptable versions). On install, the manager builds the full set of required packages and installs them together; on removal, it can flag dependencies no longer needed by anything (e.g. apt autoremove). Problems arise when requirements conflict — the classic "dependency hell" — such as two packages needing incompatible versions of the same library. Modern managers resolve most of this automatically, but conflicts and broken dependencies still occur.

Practical example

$ sudo apt install some-tool
The following additional packages will be installed:
  libfoo1 libbar2
...

Installing some-tool pulls in libfoo1 and libbar2 automatically because some-tool depends on them. Later, sudo apt autoremove can clean up such libraries if nothing else needs them anymore — keeping the system tidy and reducing unused software.

Cybersecurity relevance

Dependencies are a supply-chain consideration: a vulnerability in a widely used library affects every package that depends on it, so patching a single shared library can remediate many programs at once (and a flaw in one can expose many). Unused dependencies left installed add unnecessary attack surface, which is why cleaning them up matters. Understanding dependencies also helps interpret why a vulnerable library on a system is significant even if you did not install it directly.

Common mistakes

• Ignoring left-over dependencies, which add attack surface (use autoremove to clean up).
• Forcing installs that break dependencies, leaving the system in an inconsistent state.
• Overlooking shared-library vulnerabilities, which can affect many programs at once.

Key takeaways

• A dependency is a package another package requires (often a shared library); Linux shares libraries rather than bundling copies.
• Package managers resolve dependencies automatically on install and can remove unneeded ones (autoremove); conflicts cause "dependency hell."
• Dependencies are a supply-chain factor — a shared library's vulnerability affects all dependents, and unused dependencies add attack surface.

Check your understanding

• What does it mean for one package to depend on another, and how does the package manager handle it?
• Why is a vulnerability in a shared library significant even for programs you did not install directly?