Atualização do Fedora 43 falhando? Entenda o bug do Mesa e sua solução

Escrito por
Emanuel Negromonte
Emanuel Negromonte é Jornalista, Mestre em Tecnologia da Informação e atualmente cursa a segunda graduação em Engenharia de Software. Com 14 anos de experiência escrevendo sobre...

O bug do Mesa que travou o upgrade — e como foi corrigido

Você se prepara para um dos momentos mais aguardados: a atualização de versão do seu sistema. Executa o comando DNF system-upgrade para migrar do Fedora 42 para o Fedora 43 e é recebido com um bug chato de dependências. Foi exatamente o que alguns usuários encontraram, e o culpado tinha nome e sobrenome: uma transição delicada no Mesa — especificamente, a troca do antigo mesa-libxatracker pelo novo mesa-compat-libxatracker.

O mistério do pacote Mesa

Pense na atualização como uma “reforma de prédio”. A administração (Fedora) decidiu trocar todas as fechaduras antigas (mesa-libxatracker) por um modelo novo e compatível (mesa-compat-libxatracker). Só que uma porta importante — o driver xorg-x11-drv-vmware — ainda carregava uma plaquinha dizendo “aceitamos apenas a chave antiga”. O síndico (DNF), zeloso, travou a obra para evitar estragos.

Nos bastidores técnicos, o problema era simples de enunciar e traiçoeiro de resolver: o pacote novo provê mesa-libxatracker, mas não o obsoleta. Sem o selo oficial de substituição, o gerenciador de pacotes não autorizava a troca. O relatório do Bugzilla identificou exatamente isso e sugeriu o caminho: adicionar Obsoletes: mesa-libxatracker no pacote compat.

A solução e a corrida contra o tempo dos repositórios

A solução elegante veio rápido. Em vez de mexer em todos os consumidores (como o xorg-x11-drv-vmware), a equipe ajustou o próprio mesa-compat-libxatracker para declarar que substitui o pacote antigo. O update FEDORA-2025-d0d0983084 (versão mesa-compat-25.0.7-3.fc43) documenta explicitamente essa mudança “para evitar problemas de upgrade”. Resultado: o DNF reconhece a nova “fechadura” como sucessora legítima e a atualização segue em frente.

Mas por que alguns ainda tropeçaram depois da correção? Timing. O fluxo normal é: o update entra primeiro em updates-testing e, após validação, vai para o stable. Entre “push para estável”, primeira composição do repositório e sincronização dos espelhos, há uma janela real de tempo — e quem atualizou sem updates-testing habilitado podia, sim, continuar batendo no erro até a propagação concluir. Os carimbos do próprio bug mostram a sequência: enviado (18 de setembro), disponível em testing (19 de setembro) e, só então, promovido a stable (22 de setembro).

Transparência que inspira confiança

Outro ponto que merece aplausos é a transparência: tudo ficou público — do bug report com o diagnóstico e a sugestão de Obsoletes, ao acompanhamento do Bodhi com o advisory que explica a mudança. Até referências históricas que ajudaram a entender o contexto (como o commit que, no mesa “principal”, havia removido um obsoleto anterior por interferir no pacote compat) aparecem ligadas na discussão técnica, reforçando a cultura de engenharia aberta do Linux e do Fedora.

Por que isso importa (e o que você pode fazer)

Manter uma grande distribuição é orquestrar centenas de “fechaduras e chaves” ao mesmo tempo. Um Obsoletes bem colocado parece detalhe, mas evita aquele “tranco” na Fedora 43 upgrade. Se você ainda topou com o erro, vale repetir a atualização com --refresh e, se necessário, habilitar updates-testing temporariamente para receber o advisory já publicado — exatamente o que destrava a transição do Mesa. E, claro, consultar o advisory e o bug ajuda a verificar se você já está na versão com o ajuste.

Compartilhe este artigo