A package dependency states that one package needs another package, capability, or compatible version for installation or operation. Repository-aware package managers use this metadata to calculate a consistent set of changes rather than treating each archive in isolation.
Packages · Lesson 4
Package Dependencies
Learn how package metadata expresses required capabilities, versions, conflicts, and shared-library relationships.
Dependency Relationships
Package metadata can express more than a simple required name. Depending on the distribution format, relationships can include:
- required dependencies
- minimum, maximum, or exact version constraints
- alternatives, where any one of several providers satisfies a requirement
- recommendations or suggestions with weaker semantics
- conflicts, breaks, or replacements
- virtual capabilities supplied by more than one package
These rules let a solver choose a set of package versions compatible with the configured repositories, architecture, and installed state. A solution can require upgrades, removals, or a choice between providers, so review the proposed transaction before approving it.
What does a repository-aware dependency solver try to produce?
Shared Libraries as Dependencies
A shared library contains compiled code that multiple programs can map at runtime. Sharing reduces duplicated implementations and lets distributions update a common library independently, but programs depend on a compatible application binary interface, or ABI.
On ELF-based Linux systems, an executable can record a needed library name such as a SONAME. The dynamic linker locates a matching installed library when the program starts. Package metadata usually represents this requirement as a dependency on the package or capability providing the compatible library.
What is a shared library?
Version and ABI Compatibility
Having a file with a similar library name is not sufficient. The required ABI, architecture, symbols, and sometimes minimum version must match. Replacing a distribution library manually can break every dependent program even if the filename appears correct.
Package maintainers encode library relationships and coordinate transitions when an ABI changes. Keep native libraries under package-manager control; use supported parallel-installation, container, environment, or build mechanisms for software that needs a conflicting version.
Why might a program still fail when a similarly named library file exists?
Broken Dependency States
A dependency problem can arise from mixed repositories, interrupted operations, manually installed archives, held versions, removed files, or incompatible third-party software. Do not respond by deleting package-database files or forcing an install blindly.
First read the package manager's diagnostics, refresh only trusted repository metadata, inspect held or pinned versions, and review the proposed repair. A low-level package installer can unpack an archive without fetching all dependencies; a higher-level repository tool is usually safer for ordinary installation because it resolves the complete transaction.
What is a common limitation of installing one local package with a low-level archive tool?
Use Manage Shared Libraries in Linux to inspect runtime relationships, then compare them with package metadata in Managing Packages with RPM.
Lesson complete
You finished Package Dependencies
You can now explain how package dependency resolution works.
Recognize required, alternative, versioned, and conflicting relationships.
Relate shared-library packages to runtime ABI requirements.
Treat filenames as weaker evidence than architecture and interface compatibility.
Review a complete package-manager transaction before applying repairs.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account