¿Paquete del repositorio o paquete de cliente VPN: qué llega primero?

Instala el paquete del proveedor, el comando devuelve cero y sigue sin haber una aplicación VPN que abrir. Eso pasa cuando el paquete instalado configuró un repositorio en lugar de traer el cliente, y la diferencia se ve en lo que dejó en el disco. Que necesite ambos y en qué orden depende de tres condiciones y no del nombre que les dé el proveedor. La decisión de abajo mantiene la configuración de la fuente, la actualización de metadatos y la instalación de la aplicación como actos separados con pruebas separadas.

Qué cambia realmente cada paquete

Un paquete de configuración de repositorio escribe una entrada de fuente de APT, importa la clave de firma en la que confía esa entrada y termina. /etc/apt Su carga útil son un par de archivos y un llavero, y nada que pueda ejecutar. Un paquete de cliente incluye el demonio o la aplicación de escritorio, sus bibliotecas y sus dependencias, y es el objeto que acaba en un menú o en una unidad de systemd.

Los nombres de archivo que terminan en -release sugieren el primer tipo, pero el sufijo es una convención, no una garantía. La afirmación fiable sobre el papel de un paquete es su lista de archivos y sus dependencias, ambas legibles antes de instalar nada. Un proveedor que reorganiza su empaquetado mantiene el mismo nombre de archivo y cambia el contenido, así que una respuesta copiada de un hilo de hace dos años puede describir un paquete que ya no existe. Lea las instrucciones actuales del proveedor para la versión que ejecuta y luego compruebe qué declara el paquete.

De esa división se siguen tres etapas: registre la fuente, actualice los metadatos que alimenta y luego instale la aplicación por su nombre. La guía de instalación en Debian y Ubuntu las mantiene separadas, por eso el cliente se pide en un paso posterior y no por el paquete que configuró la fuente.

Tres condiciones que deciden el orden

La primera condición es si el proveedor publica un repositorio para su versión exacta de distribución. Una línea de fuente creada para una versión puede resolverse contra las dependencias de otra y instalar una mezcla que nadie ha probado.

La segunda es si su distribución ya trae el cliente. Cuando lo trae, el paquete de la distribución sigue las transiciones de bibliotecas y las actualizaciones de seguridad de su versión, mientras que el paquete del proveedor puede moverse más rápido y traer sus propias copias de bibliotecas compartidas.

La tercera es qué funciones necesita de verdad. Una compilación del proveedor puede incluir una implementación más reciente de un protocolo o una integración de escritorio que su distribución no ha empaquetado, y esa es una razón real para aceptar una segunda fuente. Si la compilación de la distribución cubre su uso, añadir un repositorio de terceros compra trabajo de actualización y otra relación de confianza por muy poco.

Resuelva esas tres respuestas antes de que exista la línea de fuente, porque quitarla después significa purgar el paquete y su clave. Una vez resueltas, la secuencia dentro del camino del proveedor no es una elección: fuente primero, metadatos segundo, aplicación tercero, nunca al revés.

Compruebe qué dejó el paquete de lanzamiento

Antes de instalar cualquier otra cosa, lea la lista de archivos en lugar de la descripción. En sistemas de la familia Debian el manifiesto del paquete responde qué configuró y dónde acabó la clave.

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

La primera línea muestra el archivo de fuente y la ruta del llavero, mientras que la segunda informa de qué versión pueden ofrecer las fuentes configuradas. Si apt-cache policy no imprime nada para el nombre del cliente, la actualización de metadatos no ha ocurrido o la fuente apunta a otra versión. La tercera confirma que la entrada está donde APT realmente lee.

Compare la ruta del llavero con el campo signed-by= de la línea de fuente. Una clave en el directorio equivocado produce un error de fuente no autenticada, que es un fallo distinto de un paquete no disponible.

Trate un fallo de dependencias como una etapa aparte

Instalar un .deb con dpkg -i no resuelve nada: comprueba las dependencias, informa de lo que falta y deja el paquete a medio configurar. Es el comportamiento esperado, no una descarga corrupta.

apt --fix-broken install después pide a APT un estado coherente con las fuentes que tiene. APT no sabe qué VPN quería, y su plan puede eliminar paquetes para satisfacer la restricción que encontró. Lea la transacción propuesta antes de responder que sí, y deténgase si las eliminaciones tocan algo que necesita. Repetir la reparación sin leer el plan es cómo un pequeño hueco de dependencias se convierte en un escritorio que ya no arranca.

Guarde el primer mensaje significativo del gestor de paquetes y clasifíquelo antes de actuar. Un repositorio sin firmar, un paquete que las fuentes configuradas no traen, un conflicto de versiones y un cliente que arranca y luego muere son cuatro fallos separados.

Verifique la aplicación, no el repositorio

Confirme que el cliente alcanzó el estado instalado y luego confirme que el programa arranca. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop debería informar de install ok installed con una versión, y un fallo de arranque después de eso es un problema de la aplicación y no del empaquetado.

Registre el propietario del repositorio y el paquete de la aplicación como objetos separados, para que una eliminación posterior quite el correcto y deje intacto el otro. Cuando el proveedor cambie su guía, la entrada de fuente es lo que relee; el nombre del cliente es lo que reinstala.