Após avaliar algumas opções de empacotamento do toolkit do Nvidia CUDA e passar tempo demais tentando fazer o pacote Python rembg funcionar e reconhecer a instalação das bibliotecas fornecidas por ele, decidi escrever esta publicação para que nenhum outro usuário de Arch Linux e/ou seus derivados que depende do PyPI precise passar pelo sufoco que é rodar o referido programa de remoção de fundo de imagens fora de um ambiente virtual. Pretendo percorrer os empecilhos que eu ingenuamente subestimei e os processos que idealmente devem ser seguidos para pôr ordem na casa de modo concreto.
É provável que todo usuário de Linux que realmente preza por sua saúde mental instala a maior parte de suas aplicações através de um gerenciador de pacotes. Sob o prisma funcionalista, tanto faz se o gestor em questão é apt, dnf, pacman ou qualquer outro que suporte importação, remoção e relacionamentos entre os pacotes. O aspecto descrito é, inegavelmente, essencial para a usabilidade e experiência fluida do usuário com o sistema operacional que está diante dele. Não menos crítica é a disponibilidade de pacotes que, uma vez devidamente incorporados, tendem a não ser reconfigurados manualmente pelo utilizador “padrão” — o shell que invoca os aplicativos, o próprio package manager, o git, etc.
Em distribuições tradicionalmente versionadas (Ubuntu, Debian, Zorin OS, entre outras), esse modelo permite testagem e “estabilização” amplas de atualizações de pacotes de baixo nível e dos demais componentes necessários para o sistema subjacente continuar seu ciclo constante de amadurecimento. Tal abordagem é a predominante. De toda forma, mais recentemente, distros “direto-de-fábrica” — analogia minha a rolling release — vêm ganhando popularidade, especialmente Arch Linux: nelas, a adição de novidades e correções não acontece por meio de “ondas” ou “lotes”, mas leva em conta sua disponibilidade, status de estabilidade e a capacidade do respectivo mantenedor de empacotar a nova versão.
Por outro lado, os grandes contras a tal sistemática são sua empregabilidade — claramente não combina com ambientes corporativos e produtos suportados em longo termo — e escalabilidade. Então, os desenvolvedores de softwares voltados ao mercado lucrativo concentram seus esforços de distribuição em versões longevas de sistemas “enterprise-grade” e suas variações destinadas ao usuário final; daí emerge a caça pelo kit de ferramentas do Nvidia CUDA em um sistema para o qual não há documentação por parte da desenvolvedora.
E não, conteinerização não é uma opção viável em meu caso porque quero rembg facilmente acessível pela linha de comando do host e porque minha instalação do distrobox com Debian carece de alguns ajustes.
A instalação no Debian, por exemplo, é direta ao ponto: habilitar um repositório, instalar um pacote avulso, atualizar o cache de repositórios APT, instalar o pacote do CUDA SDK e, finalmente, reiniciar o sistema.
No Arch, mais especificamente, CachyOS, o pacote cuda parece ser o equivalente ao cuda-toolkit do Debian. rembg requer também o cuDNn, de pacote homônimo (cudnn). Pois, os dois pacotes mais a dependência onnx-runtime de rembg, esta também instalada pelo pacman, funcionaram por meses, até que, em um ínterim de 2025 para 2026, o pacote cuda foi atualizado da versão 12.x para 13.x. Isso foi suficiente para a onnx-runtime não encontrar mais os arquivos que vinha usando e soltar erros por conta de sua ausência.
A seguir, testei, testei e testei; nenhuma combinação de pacotes nos repositórios oficiais do pacman funcionou. Nem reverter para versões anteriores dos pacotes cuda e cudnn; fora que seria necessário encontrar uma versão compatível da onnx-runtime arquivada no site do Arch Linux. Eventualmente, comecei a intercalar testes com o cuda via pacman e o distribuído via pip, descobrindo um novo pepino...
No período em que redijo o texto, o rembg, variante “[gpu,cli]”, requer python acima de 3.11 e abaixo de 3.14. Que assim fosse. Instalei alguns pacotes relativos ao cuda com pip do python3.11, um tanto às cegas, visto que até então não havia consultado a documentação de instalação em https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html. E, para nenhuma surpresa, não resolveram o erro de arquivo não encontrado. Sem embargo, minha perplexidade tomou novas dimensões quando múltiplos executáveis do rembg, instalados com diferentes versões do Python e seus respectivos pip’s, cansaram-se e a partir de dado ponto sequer completavam a remoção de fundo, fechando precocemente com o erro de falha de segmentação.
Cabe aqui ressalvar que, de fato, um desenvolvedor particularmente proficiente em Python teria de antemão criado um ambiente virtual — o qual vim a descobrir um bocadinho tarde que não é difícil de se manter se o próprio python o gerir — e lido a página de documentação apontada no parágrafo anterior. De tal maneira, poupar-se-ia de uma espiral de tentativas frustradas, a despeito de uma peculiaridade das implementações de Python em sistemas baseados em Linux que esse “mix’n match” revelaria e que trata da interação entre pacotes controlados por pip e pelo gerenciador nativo do SO para o superusuário.
<aside> <img src="/icons/star-of-life_blue.svg" alt="/icons/star-of-life_blue.svg" width="40px" />
Aviso: esta seção se baseia parcialmente em uma pesquisa feita com a Perplexity AI, habilitado o modelo Claude Sonnet 4.5; trechos impactados estão grafados em azul. No entanto, nada que descredite os achados da resposta ao prompt enviado foi detectado.
</aside>
À data em que relato minhas singelas experiências, as seguintes instalações de Python residem em meu host:
pacman
Homebrew
