Três perguntas separam um argumento de versão de uma investigação de função: qual componente deve fornecer a opção, qual versão desse componente está realmente instalada e o que diz o seu changelog sobre isso. O número de um plugin sozinho não responde a nenhuma delas. O atalho tentador, comparar uma versão abreviada com um mínimo de um tutorial, falha porque as strings de versão das distribuições não são decimais. Decida o que está comparando antes de comparar.

A opção pode viver no NetworkManager, no seu plugin VPN, no motor subjacente ou num frontend de desktop separado. São quatro projetos com quatro históricos de lançamento.

Quatro componentes, quatro históricos de lançamento

O editor que você vê é geralmente um plugin, e o plugin chama um motor como o binário do OpenVPN ou uma implementação do WireGuard. O próprio NetworkManager fornece o modelo de conexão, e um frontend de desktop pode adicionar os seus próprios campos por cima. Uma função pode aparecer em qualquer um deles, e atualizar um não atualiza os outros. Um motor mais novo não é prova de que o editor instalado consiga importar uma opção que o motor suporta.

Comece pelo sintoma: o campo falta na caixa de diálogo, está ausente após a importação ou está presente mas é ignorado? Essas observações apontam para componentes diferentes e exigem provas diferentes.

Analise a versão antes de compará-la

A política de pacotes do Debian define o formato como epoch, versão upstream e revisão de empacotamento. Compara-se primeiro o epoch, depois a parte upstream, depois a revisão, pelas regras de ordenação do próprio gestor de pacotes e não por aritmética decimal ou ordenação alfabética simples. O til ordena-se antes de tudo, incluindo antes do fim dessa parte, e é assim que um candidato a lançamento precede o lançamento final. É a leitura separada das partes que torna uma comparação significativa.

Não invente uma regra de conversão para algum outro esquema em que 0.8.999 pareça próximo de 0.9. A proximidade de dígitos não é prova sobre o conteúdo.

Pergunte o que está instalado e o que estaria

apt-cache policy relata a versão instalada, o candidato e o repositório de onde cada um vem, para cada pacote que você nomear. Leia-o tanto para o motor como para o plugin, e registe strings completas em vez de formas abreviadas. Os metadados locais podem estar desatualizados, e uma versão candidata não prova que um processo em execução carregou essa compilação. Se um serviço não foi reiniciado desde a atualização, o ficheiro no disco e o comportamento que observa podem divergir.

Depois leia o changelog correspondente. Uma revisão de empacotamento pode trazer patches sem adotar um novo número upstream, e é exatamente o caso em que a versão parece inalterada e o comportamento difere.

Prove a opção no componente proprietário

Para um problema de importação, inspecione os campos suportados do plugin instalado e o resultado guardado em vez de apenas a caixa de diálogo. Um rótulo, um campo de dados nativo e um argumento de motor podem ser três representações de uma mesma definição, e o sucesso ao importar um ficheiro não diz nada sobre se cada diretiva sobreviveu. Nomeie a função com precisão: por exemplo, aceitar esta diretiva preservando o seu significado para autenticação.

Se a compilação suportada para esse lançamento não tiver a integração, escolha um caminho de atualização aprovado ou outro cliente. Misturar o repositório de outro lançamento, ou aplicar um patch de código arquivado para elevar um número visível, troca um argumento de versão por um sistema não suportado.

Um relatório útil nomeia a distribuição, as versões completas dos pacotes, o proprietário da ligação ativa, a opção necessária e o comportamento guardado observado. Essa é uma pergunta reproduzível.

Artigos relacionados