Pacote de repositório ou pacote de cliente VPN: qual vem primeiro?

Você instala o pacote do fornecedor, o comando retorna zero e ainda assim não há aplicativo VPN para iniciar. Isso acontece quando o pacote instalado configurou um repositório em vez de entregar o cliente, e a diferença aparece no que ele deixou no disco. Se você precisa dos dois, e em que ordem, depende de três condições e não da nomenclatura do fornecedor. A decisão abaixo mantém a configuração da origem, a atualização dos metadados e a instalação do aplicativo como atos separados, com evidências separadas.

O que cada pacote realmente muda

Um pacote de configuração de repositório grava uma entrada de origem APT, importa a chave de assinatura em que essa entrada confia e termina. Seu conteúdo são alguns arquivos em /etc/apt mais um chaveiro, e nada executável. Um pacote de cliente entrega o daemon ou o aplicativo de desktop, suas bibliotecas e suas dependências, e é o objeto que acaba num menu ou numa unidade systemd.

Nomes de arquivo terminados em -release sugerem o primeiro tipo, mas o sufixo é uma convenção, não uma garantia. A afirmação confiável sobre o papel de um pacote é a sua lista de arquivos e as suas dependências, ambas legíveis antes de instalar qualquer coisa. Um fornecedor que reformula o empacotamento mantém o mesmo nome de arquivo e muda o conteúdo, então uma resposta copiada de um tópico de dois anos pode descrever um pacote que já não existe. Leia as instruções atuais do provedor para a versão que você executa e depois verifique o que o pacote declara.

Três etapas decorrem dessa separação: registrar a origem, atualizar os metadados que ela alimenta e instalar o aplicativo pelo nome. O guia de instalação para Debian e Ubuntu mantém tudo separado, e é por isso que o cliente é pedido numa etapa posterior e não pelo pacote que configurou a origem.

Três condições que decidem a ordem

A primeira condição é se o fornecedor publica um repositório para a sua versão exata da distribuição. Uma linha de origem feita para uma suíte pode resolver contra as dependências de outra suíte e instalar uma mistura que ninguém testou.

A segunda é se a sua distribuição já traz o cliente. Quando traz, o pacote da distribuição acompanha as transições de bibliotecas e as atualizações de segurança da sua versão, enquanto o pacote do fornecedor pode andar mais rápido e trazer cópias próprias de bibliotecas compartilhadas.

A terceira é quais recursos você realmente precisa. Uma compilação do fornecedor pode entregar uma implementação de protocolo mais nova ou uma integração com o desktop que a sua distribuição não empacotou, e essa é uma razão real para aceitar uma segunda origem. Se a compilação da distribuição cobre o seu uso, adicionar um repositório de terceiros compra trabalho de atualização e mais uma relação de confiança por muito pouco.

Resolva essas três respostas antes que a linha de origem exista, porque removê-la depois significa limpar o pacote e a sua chave. Uma vez resolvidas, a sequência dentro do caminho do fornecedor não é escolha: origem primeiro, metadados segundo, aplicativo terceiro, nunca o contrário.

Verifique o que o pacote de lançamento deixou

Antes de instalar qualquer outra coisa, leia a lista de arquivos em vez da descrição. Em sistemas da família Debian o manifesto do pacote responde o que ele configurou e onde a chave ficou.

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 linha mostra o arquivo de origem e o caminho do chaveiro, enquanto a segunda informa qual versão as origens configuradas podem oferecer. Se apt-cache policy não imprime nada para o nome do cliente, a atualização dos metadados não aconteceu ou a origem aponta para outra suíte. A terceira confirma que a entrada está onde o APT realmente lê.

Confira o caminho do chaveiro com o campo signed-by= da linha de origem. Uma chave no diretório errado produz um erro de origem não autenticada, que é uma falha diferente de um pacote indisponível.

Trate uma falha de dependência como uma etapa separada

Instalar um .deb baixado com dpkg -i não resolve nada: ele verifica as dependências, relata o que falta e deixa o pacote meio configurado. Esse é o comportamento esperado, não um download corrompido.

apt --fix-broken install então pede ao APT um estado consistente a partir das origens que você tem. O APT não sabe qual VPN você queria, e o plano dele pode remover pacotes para satisfazer a restrição que encontrou. Leia a transação proposta antes de responder sim, e pare se as remoções tocarem em algo de que você precisa. Repetir o reparo sem ler o plano é como uma pequena lacuna de dependência vira uma área de trabalho que não inicia mais.

Guarde a primeira mensagem significativa do gerenciador de pacotes e classifique-a antes de agir. Um repositório sem assinatura, um pacote que as origens configuradas não contêm, um conflito de versões e um cliente que inicia e depois morre são quatro falhas distintas.

Verifique o aplicativo, não o repositório

Confirme que o cliente chegou ao estado instalado e depois confirme que o programa inicia. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop deve relatar install ok installed com uma versão, e uma falha de inicialização depois disso é um problema do aplicativo e não do empacotamento.

Registre o dono do repositório e o pacote do aplicativo como objetos separados, para que uma remoção posterior leve o correto e deixe o outro intacto. Quando o fornecedor muda o seu guia, a entrada de origem é o que você relê; o nome do cliente é o que você reinstala.