Qual pacote OpenVPN uma versão do Linux realmente consegue suportar

Instruções que nomeiam uma versão específica do OpenVPN normalmente codificam uma funcionalidade, e o número da versão é apenas um substituto dela. Quando as lê, a distribuição pode fornecer algo mais recente do que a versão indicada e ainda assim faltar a integração de que precisa, ou fornecer algo mais antigo que já cobre o requisito. Tratar o número como objetivo produz alterações de repositório que não resolvem nada. Tratá-lo como sintoma de um requisito produz uma decisão muito menor.

Três perguntas separam os dois casos: qual implementação, qual versão base e quem cuida das atualizações.

Um número de versão não é um requisito de funcionalidade

Pergunte do que a conexão precisa antes de perguntar qual pacote o fornece. Um perfil pode exigir uma cifra, um modo TLS, um plugin de autenticação ou uma interface de gestão, e qualquer um deles pode faltar numa compilação que declara uma string de versão satisfatória. Por outro lado, uma compilação ligeiramente mais antiga pode implementar tudo o que o perfil usa. A string de versão é um resumo escrito por quem empacota, não uma lista de funcionalidades.

Esclareça se a instrução significa 'esta funcionalidade ou posterior' ou 'exatamente esta compilação foi testada'. As duas respostas levam a repositórios diferentes.

O codinome tem de corresponder à versão base

Os repositórios são indexados pelo codinome da distribuição, e o nome da versão de uma derivada não é o codinome da sua base. Leia /etc/os-release para VERSION_CODENAME e ID_LIKE, e confirme qual versão base a derivada segue. Uma resposta antiga que associava uma versão de desktop a um codinome do Ubuntu não diz nada sobre a seguinte. Adivinhar o codinome é como um sistema acaba a puxar pacotes compilados contra outra biblioteca C.

Verifique o que o gestor de pacotes já oferece com apt-cache policy openvpn antes de acrescentar qualquer coisa. Se o candidato instalado satisfaz o requisito, a questão do repositório desaparece.

A que um repositório upstream realmente se liga

Um canal upstream publica compilações para versões base específicas, e as suas instruções emparelham uma linha de repositório com uma chave de assinatura e um codinome suportado. Essas partes não são espaços reservados a preencher com qualquer codinome que conheça. As dependências são resolvidas contra a versão a que a compilação se destinava, por isso um pacote que instala sem erros pode ainda quebrar software não relacionado que partilha uma biblioteca.

Leia o guia do repositório para a implementação que escolheu, e siga a tabela de compatibilidade atual dele em vez da cópia de um blog mais antigo.

Instalar não é integrar

Substituir o binário openvpn não acrescenta um plugin NetworkManager em falta, uma caixa de importação ou um editor de ambiente de trabalho. Esses vivem em pacotes separados como network-manager-openvpn e a sua contraparte de ambiente de trabalho, e têm a sua própria relação de versão com a biblioteca cliente. O OpenVPN 3 Linux é ainda outra implementação, com o seu próprio modelo de sessão e de configuração, por isso os seus pacotes não são substitutos diretos de um fluxo de trabalho com perfil 2.x.

Decida qual componente é dono do túnel em execução antes de instalar seja o que for. Dois gestores num só anfitrião produzem a mesma confusão de túnel duplicado que dois clientes.

Anote as três decisões

Registe a implementação, a versão base e o responsável pelas atualizações, e anote qual deles se espera que mude. Esse registo é o que uma atualização futura lê quando a linha do repositório deixa de funcionar após uma versão da distribuição. Sem ele, a pessoa seguinte repete o palpite do codinome com um número mais recente.

Se a versão base já não for suportada pelo canal de que precisa, a resposta é uma migração de plataforma, não um repositório de três versões atrás.