Odio empaquetar mi software para Linux

Artículo original ↗ Discusión en Hacker News ↗

Los desarrolladores independientes están teniendo dificultades para distribuir aplicaciones de Linux en un ecosistema fragmentado de distros, gestores de paquetes y supuestos de ejecución. Muchos sostienen que es irrealista que un mantenedor individual apoye todos los formatos y abogan en su lugar por distribuir binarios estáticos sencillos o dejar el empaquetado a los mantenedores de las distros, aunque eso limite el alcance y la comodidad de las actualizaciones automáticas. Otros exploran alternativas como binarios con autoactualización, enfoques tipo contenedor (Flatpak, Docker, Nix) o herramientas externas, pero no hay consenso sobre una solución universal y de baja fricción.

Alcance del problema

  • El hilo coincide en que el empaquetado en Linux está fragmentado: muchas distros, muchos gestores de paquetes, además de capas más nuevas (Flatpak, Snap, AppImage, Nix, Homebrew, etc.).
  • A los mantenedores individuales les resulta difícil cubrir todas las distros y mantener el flujo de actualizaciones, especialmente para dependencias no triviales (p. ej., Rust con muchas crates, Python, etc.).

¿Quién debería empaquetar?

  • Una postura: el desarrollador debería principalmente publicar el código fuente, instrucciones de compilación sencillas y, quizá, un tarball o un binario estático; se espera que los mantenedores de las distros hagan el empaquetado específico para cada distro.
  • Contrapunto: depender de las distros significa que el software puede quedar efectivamente indisponible si nadie asume el mantenimiento; los usuarios pueden no tener las habilidades o el tiempo para empaquetar o compilar.
  • Algunos argumentan que esto ha “funcionado durante décadas”; otros señalan que filtra software y frustra a los usuarios no expertos.

Binarios estáticos y con autoactualización

  • Muchos consideran que un único binario estático (o mayormente estático) con autoactualización integrada es la solución más pragmática y multiplataforma para distintas distros, especialmente para CLI/TUI.
  • Ejemplos citados: otras herramientas en Rust, el propio actualizador de Firefox, varias utilidades de Go/Rust.
  • Preocupaciones: rendimiento (musl frente a glibc), seguridad de los ejecutables que se modifican a sí mismos y rechazo social en algunos círculos de Linux.

Canales de distribución alternativos

  • Soluciones tipo contenedor: Docker/Podman/systemd-nspawn o distribuir un userspace completo/squashfs se ven como fiables pero pesadas, especialmente para sistemas embebidos o con poco almacenamiento.
  • Steam/Proton: sugerido como una forma de obtener runtimes estables a largo plazo para apps GUI, pero la experiencia de usuario es rara para cosas que no son juegos y depende de una plataforma propietaria.
  • Flatpak: funciona bien para apps GUI, pero el soporte para CLI/TUI y el modelo de permisos se ven como incómodos.
  • Nix, OBS, PPAs, repositorios Debian personales, Homebrew en Linux se mencionan como útiles, pero cada uno añade su propia complejidad y curva de aprendizaje.

Compilación desde el código fuente y herramientas

  • El tradicional ./configure && make && make install (o cargo install) sigue viéndose por algunos como viable; otros dicen que a menudo falla por desajustes de dependencias.
  • Varios comentarios sugieren usar herramientas modernas y CI (Nix, GitHub Actions, Open Build Service, checkinstall) e incluso LLMs para generar automáticamente metadatos de empaquetado.

Comparaciones con Windows/macOS

  • Varios participantes afirman que empaquetar en Windows es más fácil en la práctica: incluir todas las DLL con la app y distribuir instaladores.
  • macOS y las plataformas móviles tienen su propia burocracia (certificados, tiendas), pero al menos presentan una vía relativamente unificada, a diferencia del ecosistema Linux.