Odeio empacotar meu software para Linux

Artigo original ↗ Discussão no Hacker News ↗

Desenvolvedores independentes estão tendo dificuldade para distribuir aplicativos Linux em um ecossistema fragmentado de distros, gerenciadores de pacotes e suposições de runtime. Muitos argumentam que é irrealista para um mantenedor solo suportar todos os formatos e defendem, em vez disso, ou distribuir binários estáticos simples ou deixar o empacotamento para os mantenedores das distros, mesmo que isso limite o alcance e a conveniência de autoatualização. Outros exploram alternativas como binários com autoatualização, abordagens em estilo contêiner (Flatpak, Docker, Nix) ou ferramentas externas, mas não há consenso sobre uma solução universal e de baixa fricção.

Escopo do Problema

  • A discussão concorda que o empacotamento no Linux é fragmentado: muitas distros, muitos gerenciadores de pacotes, além de camadas mais novas (Flatpak, Snap, AppImage, Nix, Homebrew, etc.).
  • Mantenedores solo acham difícil cobrir todas as distros e manter as atualizações fluindo, especialmente para dependências não triviais (por exemplo, Rust com muitos crates, Python, etc.).

Quem Deve Empacotar?

  • Uma corrente: o desenvolvedor deve principalmente distribuir o código-fonte, instruções simples de compilação e talvez um tarball ou um binário estático; espera-se que os mantenedores das distros façam o empacotamento específico da distro.
  • Contraponto: depender das distros significa que o software pode ficar, na prática, indisponível se nenhum mantenedor aparecer; os usuários podem não ter habilidade/tempo para empacotar ou compilar.
  • Alguns argumentam que isso “funcionou por décadas”; outros observam que filtra software e frustra usuários não especialistas.

Binários Estáticos e com Autoatualização

  • Muitos veem um único binário estático (ou majoritariamente estático) com autoatualização embutida como a solução mais pragmática entre distros, especialmente para CLIs/TUIs.
  • Exemplos citados: outras ferramentas em Rust, o próprio atualizador do Firefox, vários utilitários em Go/Rust.
  • Preocupações: desempenho (musl vs glibc), segurança de executáveis que se modificam sozinhos e reação negativa de parte da comunidade Linux.

Canais Alternativos de Distribuição

  • Soluções tipo contêiner: Docker/Podman/systemd-nspawn ou distribuir um userspace inteiro/squashfs são vistos como confiáveis, mas pesados, especialmente para sistemas embarcados ou com pouco armazenamento.
  • Steam/Proton: sugerido como uma forma de obter runtimes estáveis de longo prazo para apps GUI, mas a UX é estranha para não-jogos e depende de uma plataforma proprietária.
  • Flatpak: funciona bem para apps GUI, mas o suporte a CLI/TUI e o modelo de permissões são vistos como complicados.
  • Nix, OBS, PPAs, repositórios Debian pessoais, Homebrew no Linux foram mencionados como úteis, mas cada um adiciona sua própria complexidade e curva de aprendizado.

Compilação a partir do Código-Fonte e Ferramentas

  • O tradicional ./configure && make && make install (ou cargo install) ainda é visto por alguns como viável; outros dizem que muitas vezes falha por incompatibilidades de dependências.
  • Vários comentários sugerem usar ferramentas modernas e CI (Nix, GitHub Actions, Open Build Service, checkinstall) e até LLMs para gerar automaticamente metadados de empacotamento.

Comparações com Windows/macOS

  • Vários participantes afirmam que empacotar para Windows é mais fácil na prática: agrupar todos os DLLs com o app e enviar instaladores.
  • macOS e plataformas móveis têm sua própria burocracia (certificados, lojas), mas pelo menos apresentam um caminho relativamente unificado, ao contrário do ecossistema Linux.