The C-Shaped Hole in Package Management
3 months ago
- #package-management
- #dependency-resolution
- #open-source
- System package managers (e.g., apt, dnf) and language package managers (e.g., pip, npm) serve different purposes but overlap in managing C libraries.
- System package managers focus on delivering applications and maintaining one version per package, simplifying dependency resolution but limiting flexibility.
- Language package managers prioritize developer needs, allowing multiple versions and cross-platform compatibility but struggle with C dependencies.
- C libraries sit at the intersection of both systems, lacking a canonical package registry and causing friction between ecosystems.
- Distros package C libraries differently (e.g., libssl-dev on Debian, openssl-devel on Fedora), creating inconsistency.
- Language-specific solutions (e.g., Python wheels, Node's node-gyp) handle C bindings independently but lack machine-readable dependency declarations.
- Phantom dependencies (e.g., OpenBLAS in NumPy) are bundled but not declared in metadata, complicating security and funding efforts.
- Conda bridges system and language packages but remains niche due to complexity and performance issues.
- Nix and Guix offer reproducible builds but still absorb language packages rather than enabling cross-ecosystem communication.
- Tools like ecosyste.ms aim to map symbols to system libraries, improving visibility for security and sustainability.