The new APT 3.0 solver

Original Article ↗ Hacker News Discussion ↗

Libc / glibc versioning and binary compatibility

  • Many comments focus on why binaries often break on older systems:
    • glibc uses symbol versioning; building on a newer distro can pull in newer symbols that don’t exist on old systems.
    • Toolchains default to linking against the latest glibc and headers; targeting older versions is possible but awkward (cross-toolchains, chroot, Docker, Zig, etc.).
  • Some argue this hurts Linux desktop adoption vs. Windows, where old binaries tend to keep working.
  • Workarounds discussed:
    • Cross-compiling against an older glibc with tools like crosstool-ng.
    • Custom “glibc compatibility” shims and polyfill tools.
    • Building against musl and patching binaries.
    • Zig (and cargo-zigbuild) as an easier way to target old glibc.

Static linking, containers, and deployment models

  • Debate over static linking vs. dynamic linking + Docker/containers:
    • Pro-static: simpler deployment, fewer env issues; “wasteful” duplication considered acceptable given storage sizes.
    • Anti-static: duplication of runtimes seen as inelegant; shared libraries and package managers (apt, etc.) are considered better by others.
  • Some see containers as an embarrassing workaround for dependency hell; others view them as a legitimate, lightweight alternative to VMs.
  • Flatpak, NixOS, Guix, and “functional package management” are praised for reproducibility and isolation.

APT solver3 behavior and dependency-solving design

  • New solver always preserves manually installed packages (“world”) and backtracks like a DPLL SAT solver.
  • Some like the “never auto-remove manual packages” behavior as intuitive.
  • Others note it can block upgrades when old manually installed packages conflict; preference for explicit prompts/suggestions instead.
  • There is interest in deterministic, testable solvers; some criticize traditional install-time resolution as inherently hard to test.
  • Comparisons drawn to libsolv-based systems and newer SAT/PubGrub-based resolvers in other ecosystems.

System maintenance, upgrades, and configuration

  • Strong split between:
    • Rebuilding systems on major releases (fresh installs, /home separate, /etc in version control).
    • Long-lived in-place upgrades (Debian users citing decades of stable upgrades).
  • Tools like etckeeper, “world”/manual package lists, rpm-ostree status, and apt-mark showmanual are highlighted for tracking intent and cleaning old dependencies.

Other themes

  • Desire for first-class multi-version library support instead of ad-hoc package renames.
  • Confusion from non-Debian readers about “APT” vs. “GPT.”
  • Brief controversy referenced about distro maintainers changing app defaults (e.g., KeePassXC variants), raising concerns about breaking user setups.