Que paquete de OpenVPN pode soportar de verdade unha versión de Linux

As instrucións que nomean unha versión concreta de OpenVPN adoitan codificar unha función, e o número de versión só é un indicio dela. Para cando as leas, a distribución pode entregar algo máis novo ca versión nomeada e seguir sen a integración que necesitas, ou entregar algo máis vello que xa cobre o requisito. Tratar o número como o obxectivo produce cambios no repositorio que non resolven nada. Tratalo como un síntoma dun requisito produce unha decisión moito máis pequena.

Tres preguntas separan ambas as cousas: que implementación, que versión base e quen é dono das actualizacións.

Un número de versión non é un requisito de función

Pregunta que necesita a conexión antes de preguntar que paquete o fornece. Un perfil pode requirir un cifrado, un modo TLS, un complemento de autenticación ou unha interface de xestión, e calquera deles pode faltar nunha compilación que declara unha cadea de versión satisfactoria. Ao revés, unha compilación algo máis antiga pode implementar todo o que usa o perfil. A cadea de versión é un resumo escrito por quen empaqueta, non unha lista de funcións.

Aclara se a instrución significa «esta función ou posterior» ou «probouse exactamente esta compilación». As dúas respostas levan a repositorios distintos.

O nome en clave ten que coincidir coa versión base

Os repositorios indéxanse polo nome en clave da distribución, e o nome de versión dunha derivada non é o nome en clave da súa base. Le /etc/os-release para VERSION_CODENAME e ID_LIKE, e confirma que versión base segue a derivada. Unha resposta antiga que asignaba unha versión de escritorio a un nome en clave de Ubuntu non di nada sobre a seguinte. Adiviñar o nome en clave é como un sistema acaba baixando paquetes compilados contra outra biblioteca C.

Comproba o que xa ofrece o xestor de paquetes con apt-cache policy openvpn antes de engadir nada. Se o candidato instalado satisfai o requisito, a pregunta do repositorio desaparece.

A que se liga realmente un repositorio upstream

Unha canle upstream publica compilacións para versións base concretas, e as súas instrucións emparellan unha liña de repositorio cunha clave de sinatura e un nome en clave compatible. Esas partes non son marcadores que poidas substituír por calquera nome en clave que coñezas. As dependencias resólvense contra a versión á que apuntaba a compilación, así que un paquete que se instala limpiamente pode romper igualmente software non relacionado que comparte unha biblioteca.

Le a guía do repositorio da implementación que escolliches e segue a súa táboa de compatibilidade actual en vez da copia dun blog antigo.

Instalar non é integrar

Substituír o binario openvpn non engade un complemento de NetworkManager que falta, un diálogo de importación nin un editor de escritorio. Eses viven en paquetes separados como network-manager-openvpn e a súa contraparte de escritorio, e teñen a súa propia relación de versións coa biblioteca cliente. OpenVPN 3 Linux é aínda outra implementación, co seu propio modelo de sesión e configuración, así que os seus paquetes non son substitutos directos para un fluxo de traballo con perfil 2.x.

Decide que compoñente é dono do túnel en execución antes de instalar nada. Dous xestores nun mesmo equipo producen a mesma confusión de túnel duplicado que dous clientes.

Anota as tres decisións

Rexistra a implementación, a versión base e o responsable das actualizacións, e anota cal delas se espera que cambie. Ese rexistro é o que lerá unha futura actualización cando a liña do repositorio deixe de funcionar tras unha versión da distribución. Sen el, a seguinte persoa repite a adiviña do nome en clave cun número máis novo.

Se a canle que necesitas xa non admite a versión base, a resposta é unha migración de plataforma, non un repositorio de hai tres versións.