Nome da distro, glibc ou compilador: o que o instalador verifica

O instalador imprime “unsupported distribution”, você edita uma string e ele prossegue até falhar um minuto depois com um erro do carregador. Essa sequência é o sintoma que vale reconhecer: a primeira falha foi uma verificação de reconhecimento e a segunda é um limite de compatibilidade. São dois problemas diferentes que por acaso aparecem no mesmo terminal. Editar a verificação só pode levá-lo do primeiro ao segundo.

O sintoma: o instalador para na sua derivada

Um script que lê um nome de distribuição e se recusa a continuar está dizendo que o autor dele não testou a sua derivada. Isso é uma declaração de suporte e não um fato técnico, e muitas vezes está errado no sentido de que o pacote funcionaria bem.

O problema começa quando a gambiarra vira o plano. Alterar um arquivo de identidade faz a verificação passar, e o pacote então carrega, ou não carrega, contra o ambiente de execução que está realmente instalado. Se falhar ali, nenhuma edição adicional de identidade ajudará.

Então o passo útil é descobrir qual pergunta o instalador fez, e depois descobrir se a resposta teria importado. São duas investigações separadas e apenas a segunda prevê se o pacote vai funcionar.

Três versões que as pessoas chamam de versão do sistema

Uma versão de distribuição nomeia um ambiente empacotado. Uma versão de biblioteca C nomeia uma implementação de ambiente de execução e a sua versão. Uma versão de compilador nomeia uma cadeia de ferramentas. Numa conversa as pessoas chamam as três de “a versão do sistema”, e num instalador elas não são intercambiáveis.

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

Um aplicativo pré-compilado espera o ambiente de execução presente quando foi ligado. Trocar compiladores no host não o liga de novo, e uma cadeia de ferramentas mais nova não muda nada nos símbolos do carregador que o binário pede. A arquitetura conta outra vez separadamente, porque um pacote de 32 bits num sistema de 64 bits falha por razões que nenhuma string de versão explica.

Guarde as quatro saídas com o relatório. Coletá-las leva dez segundos e respondem à maioria das perguntas que um mantenedor faria por e-mail.

Leia o erro, não a verificação

O primeiro erro de inicialização é a evidência. Uma mensagem sobre um objeto compartilhado ausente, ou sobre uma versão de símbolo que o carregador não consegue satisfazer, é um problema de dependência do ambiente de execução. Uma mensagem que repete o nome da distribuição é de novo a verificação de reconhecimento, noutro lugar.

A documentação do ligador dinâmico descreve como funciona a busca de bibliotecas e onde o carregador procura. Mudar um rótulo de distribuição não adiciona um diretório a esse caminho de busca, e é por isso que a segunda falha parece sem relação com a primeira.

Não recorra a ldd num executável baixado como primeiro passo casual. O próprio manual avisa que ele pode executar o programa em algumas circunstâncias, e executar um instalador não confiável é exatamente o caso a que esse aviso se refere.

Por que editar a string não ajuda

Falsificar a identidade do sistema operacional muda como cada programa da máquina vê a si mesmo. Os gerenciadores de pacotes, as ferramentas de suporte e outros aplicativos leem o mesmo arquivo, e um valor que satisfaz um instalador pode confundir outra coisa meses depois.

Substituir bibliotecas do host por arquivos de outra distribuição é pior. Pode quebrar software não relacionado, é invisível para o gerenciador de pacotes e exige um plano de manutenção que ninguém escreve. Essas mudanças não são justificadas por um único instalador restritivo.

Se a verificação é realmente um defeito de reconhecimento, o mantenedor pode confirmá-lo e descrever a correção suportada. Se não é um defeito, o caminho suportado é uma compilação para a sua plataforma, e essa resposta não muda porque a string foi editada.

Escreva um relatório sobre o qual o mantenedor possa agir

Anote a distribuição e a versão, a arquitetura, a versão do VPN, a condição exata que foi rejeitada e o primeiro erro do ambiente de execução se chegou até lá. Indique se modificou algo, porque um relatório de um sistema modificado é outro relatório.

Deixe o instalador original sem alterações e descreva a verificação em vez de contorná-la. Essa distinção permite ao mantenedor separar uma regra de reconhecimento demasiado estreita de um limite real de compatibilidade binária, que são dois bugs muito diferentes com duas correções muito diferentes.

Se a resposta for que a sua plataforma não é suportada, isso é um resultado utilizável. Diz para procurar uma compilação suportada em vez de passar outra noite em arquivos de identidade que nunca foram o problema.