A versão rolling release do projeto openSUSE, o Tumbleweed, fará a substituição definitiva de seu instalador padrão antes do final de 2026. O sistema abandonará o YaST, ferramenta que acompanhou a distribuição por quase três décadas, para adotar o novo instalador Agama. A alteração nas imagens principais oferecidas no portal oficial ocorrerá nas próximas semanas, dependendo apenas da fase final de validação.
Historicamente, o Tumbleweed funciona como a vitrine tecnológica da distribuição, adotando novas tecnologias muito antes das versões de lançamento fixo. No entanto, a equipe de engenharia inverteu essa lógica com o Agama. Enquanto o openSUSE Leap 16.0 já utiliza o novo instalador desde seus primeiros lançamentos, o Tumbleweed teve a transição retida deliberadamente. O projeto aguardou até que o Agama alcançasse a paridade técnica com as funções essenciais do YaST ou até que os desenvolvedores decidissem descartar recursos antigos de forma consciente.
Risco de dependências em um sistema rolling release
O YaST (Yet another Setup Tool) teve sua primeira versão lançada em abril de 1995 e construiu a identidade visual e administrativa do (open)SUSE. Apesar dessa importância histórica, a ferramenta entrou em regime de manutenção mínima e não recebe mais desenvolvimento ativo de novos recursos.
Para uma distribuição rolling release, manter um software central nesse estado de desenvolvimento representa um problema de engenharia contínuo. Como as bibliotecas base, os pacotes do sistema e o ecossistema Linux evoluem rapidamente no Tumbleweed, um instalador estagnado corre o risco de quebrar a cada grande atualização de dependências. A substituição pelo Agama elimina esse gargalo técnico e transfere o processo de instalação para uma base de código mantida ativamente.
O fim da seleção granular de pacotes
A mudança de instalador altera profundamente a forma como os administradores interagem com a configuração inicial do sistema. O YaST era conhecido por permitir uma seleção granular de software, dando ao usuário a capacidade de escolher ou remover pacotes individuais antes mesmo do início da cópia dos arquivos para o disco.
O Agama não oferece essa possibilidade. A nova interface trabalha exclusivamente com um conjunto curado de padrões de software (patterns). A lista disponível durante a instalação também é restrita e não exibe todos os padrões presentes nos repositórios oficiais da distribuição. A equipe do openSUSE classifica essa limitação como uma escolha de design intencional, focada em simplificar o fluxo de instalação inicial e transferir ajustes específicos de pacotes para a gestão pós-instalação.
Validação no openQA e infraestruturas complexas
O projeto liberou duas imagens baseadas no Agama para testes comunitários antes do corte definitivo. A primeira é um instalador offline, que inclui um cache de pacotes pré-preenchido capaz de concluir a instalação sem conexão com a internet. A segunda opção é uma imagem netinstall (instalação via rede). Como essa versão foi alocada fora do diretório padrão de ISOs e movida para a pasta de “appliances”, ela passou despercebida por parte dos usuários nos últimos meses.
A substituição oficial nos servidores de download está condicionada aos resultados dos testes automatizados. O openSUSE depende fortemente da plataforma openQA para validar suas compilações diárias. No momento, a cobertura completa de testes para o Agama ainda está sendo construída. As rotinas de verificação estão sendo adicionadas ao fluxo de trabalho de staging, ambiente onde a infraestrutura básica já existe, mas os testes específicos do novo instalador ainda precisam entrar em execução plena.
Para garantir a estabilidade do lançamento, os desenvolvedores solicitaram que a comunidade teste o Agama em cenários menos comuns de hardware e configuração. O foco atual da validação inclui:
- Sistemas com múltiplos discos físicos.
- Lógica de particionamento baseada em LVM.
- Arranjos de armazenamento em RAID.
- Instalações gerenciadas via console serial.
- Instalações puramente offline.
Qualquer discrepância de comportamento em relação ao resultado que seria obtido com o YaST nesses cenários deve ser documentada e relatada como bug. Além de eventuais falhas de software, o projeto também indicou a necessidade de atualizar a documentação da distribuição, uma vez que procedimentos como instalações baseadas em perfis e acessos via console ainda carecem de guias detalhados para a nova ferramenta.