Package Dependencies

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.

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.

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.

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.

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.

Use Manage Shared Libraries in Linux to inspect runtime relationships, then compare them with package metadata in Managing Packages with RPM.

Summary

You can now explain how package dependency resolution works.

1. Recognize required, alternative, versioned, and conflicting relationships.
2. Relate shared-library packages to runtime ABI requirements.
3. Treat filenames as weaker evidence than architecture and interface compatibility.
4. Review a complete package-manager transaction before applying repairs.