Paquete de repositorio ou paquete cliente VPN: cal primeiro?

Instala o paquete do provedor, o comando devolve cero, e aínda así non hai ningunha aplicación VPN para iniciar. Isto ocorre cando o paquete que instalou configurou un repositorio en vez de incluír o cliente, e a diferenza vese no que deixou no disco. Se necesita ambos os dous e en que orde depende de tres condicións, non da nomenclatura do provedor. A decisión de abaixo mantén a configuración da fonte, a actualización dos metadatos e a instalación da aplicación como actos separados con probas separadas.

Que cambia realmente cada paquete

Un paquete de configuración de repositorio escribe unha entrada de fonte APT, importa a chave de sinatura na que confía esa entrada e remata. A súa carga útil son un par de ficheiros baixo /etc/apt máis un chaveiro, e nada que poida executar. Un paquete cliente inclúe o daemon ou a aplicación de escritorio, as súas bibliotecas e as súas dependencias, e é o obxecto que acaba nun menú ou nunha unidade systemd.

Os nomes de ficheiro que rematan en -release suxiren o primeiro tipo, pero o sufixo é unha convención, non unha garantía. A afirmación fiable sobre o papel dun paquete é a súa lista de ficheiros e as súas dependencias, ambas lexibles antes de instalar nada. Un provedor que reformula o seu empaquetado mantén o mesmo nome de ficheiro e cambia o contido, así que unha resposta copiada dun fío de hai dous anos pode describir un paquete que xa non existe. Lea as instrucións actuais do provedor para a versión que executa e despois comprobe o que declara o paquete.

Desa separación seguen tres etapas: rexistrar a fonte, actualizar os metadatos que alimenta e despois instalar a aplicación polo seu nome. A guía de instalación de Debian e Ubuntu manténas separadas, e por iso o cliente solicítase nun paso posterior e non no paquete que configurou a fonte.

Tres condicións que deciden a orde

A primeira condición é se o provedor publica un repositorio para a súa versión exacta da distribución. Unha liña de fonte creada para unha suite pode resolverse contra as dependencias doutra suite e instalar unha mestura que ninguén probou.

A segunda é se a súa distribución xa trae o cliente. Cando o trae, o paquete da distribución segue as transicións de bibliotecas e as actualizacións de seguridade da súa versión, mentres que o paquete do provedor pode moverse máis rápido e traer as súas propias copias de bibliotecas compartidas.

A terceira é que funcións necesita realmente. Unha compilación do provedor pode incluír unha implementación de protocolo máis nova ou unha integración de escritorio que a súa distribución non empaquetou, e esa é unha razón real para aceptar unha segunda fonte. Se a compilación da distribución cobre o seu uso, engadir un repositorio de terceiros compra traballo de actualización e outra relación de confianza por moi pouco.

Resolva esas tres respostas antes de que exista a liña de fonte, porque retirala despois significa purgar o paquete e a súa chave. Unha vez resoltas, a secuencia dentro da vía do provedor non é unha escolla: fonte primeiro, metadatos segundo, aplicación terceira, nunca ao revés.

Comprobe o que deixou o paquete de publicación

Antes de instalar calquera outra cousa, lea a lista de ficheiros en vez da descrición. Nos sistemas da familia Debian o manifesto do paquete responde que configurou e onde quedou a chave.

dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/

A primeira liña mostra o ficheiro de fonte e a ruta do chaveiro, mentres que a segunda indica que versión poden ofrecer as fontes configuradas. Se apt-cache policy non imprime nada para o nome do cliente, a actualización dos metadatos non se produciu ou a fonte apunta a outra suite. A terceira confirma que a entrada está onde APT le realmente.

Faga coincidir a ruta do chaveiro co campo signed-by= da liña de fonte. Unha chave nun directorio incorrecto produce un erro de fonte non autenticada, que é un fallo distinto dun paquete non dispoñible.

Trate un fallo de dependencias como unha etapa separada

Instalar un .deb descargado con dpkg -i non resolve nada: comproba as dependencias, informa do que falta e deixa o paquete a medio configurar. Ese é o comportamento esperado, non unha descarga corrupta.

apt --fix-broken install pide entón a APT un estado coherente a partir das fontes que ten. APT non sabe que VPN quería, e o seu plan pode retirar paquetes para satisfacer a restrición que atopou. Lea a transacción proposta antes de responder si, e detéñase se as retiradas tocan algo que necesita. Repetir a reparación sen ler o plan é como un pequeno oco de dependencias se converte nun escritorio que xa non arranca.

Garde a primeira mensaxe significativa do xestor de paquetes e clasifíquea antes de actuar. Un repositorio sen sinar, un paquete que as fontes configuradas non inclúen, un conflito de versións e un cliente que arranca e logo morre son catro fallos distintos.

Verifique a aplicación, non o repositorio

Confirme que o cliente acadou o estado instalado e despois confirme que o programa arranca. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop debería informar de install ok installed cunha versión, e un fallo de inicio despois diso é un problema da aplicación e non do empaquetado.

Rexiste o propietario do repositorio e o paquete da aplicación como obxectos separados, para que unha retirada posterior quite o correcto e deixe o outro intacto. Cando o provedor cambie a súa guía, a entrada de fonte é o que volve ler; o nome do cliente é o que reinstala.