仓库包还是 VPN 客户端包：先装哪一个

你装完厂商的包，命令返回零，却依然没有可启动的 VPN 应用。这种情况出现在所装包配置了一个仓库、而并未随包提供客户端的时候，差别就体现在它往磁盘上放了什么。两者是否都需要、以及先后顺序，取决于三个条件，而不是厂商的命名。下面的判断把软件源配置、元数据刷新和应用安装保留为三个独立动作，各自留有独立证据。

每个包实际改变了什么

仓库配置包会写入一条 APT 源，导入该源所信任的签名密钥，然后就退出。它的内容只有 /etc/apt 下的几个文件加一个密钥环，没有任何可执行的东西。客户端包则带来守护进程或桌面应用、它的库和依赖，最终出现在菜单或 systemd 单元里的正是它。

以 -release 结尾的文件名暗示的是前者，但这个后缀只是惯例，不是保证。判断一个包的角色，可靠依据是它的文件清单和依赖，两者都能在动手安装前读到。厂商若重做打包方式，会保留同样的文件名而改掉内容，所以从两年前的帖子里抄来的答案，可能描述的是一个已经不存在的包。请按你所运行的版本去读厂商当前的说明，然后再核对这个包到底声明了什么。

这一分割带来三个阶段：注册软件源、刷新它供应的元数据、再按名称安装应用。Debian 与 Ubuntu 安装指南把这几步分开，因此客户端是在更靠后的一步被要求的，而不是由配置源的那个包一并装好。

决定顺序的三个条件

第一个条件：厂商是否为你这个确切的发行版版本提供了仓库。为某个发行版套件写的源行，可能会按另一个套件的依赖关系去解析，并装出一套没人验证过的组合。

第二个条件：你的发行版本身是否已经带有客户端。若已带有，发行版包会跟随你这个版本的库过渡和安全更新，而厂商包可能更新更快，并自带一份共享库副本。

第三个条件：你真正需要哪些功能。厂商构建可能提供更新的协议实现，或提供你的发行版尚未打包的桌面集成，这才是接受第二个软件源的正当理由。若发行版的构建已覆盖你的用途，加一个第三方仓库就只换来更新维护的负担和又一份信任关系，收益很小。

请在源行存在之前就把这三个答案定下来，因为日后移除它意味着清除这个包及其密钥。一旦定下，厂商路线内部的顺序就没有选择余地：先源、再元数据、后应用，绝不能颠倒。

检查发布包留下了什么

在安装别的东西之前，先读文件清单而不是描述。在 Debian 系系统上，包的文件清单会回答它配置了什么、密钥落在哪里。

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

第一行显示源文件和密钥环路径，第二行报告已配置的源能提供哪个版本。如果 apt-cache policy 对客户端名称没有任何输出，说明元数据没有刷新，或者源指向了另一个套件。第三行则确认这条源确实位于 APT 真正读取的位置。

把密钥环路径与源行里的 signed-by= 字段对上。密钥放在错误的目录会产生“源未通过认证”的错误，这与“包不可用”是两种不同的故障。

把依赖失败当作单独一个阶段

用 dpkg -i 安装下载来的 .deb 解决不了任何问题：它会检查依赖、报告缺什么，然后把这个包留在配置了一半的状态。这是预期行为，不是下载损坏。

随后 apt --fix-broken install 会要求 APT 在现有源的基础上给出一致状态。APT 并不知道你要的是哪个 VPN，它的方案可能为了满足所发现的约束而移除软件包。在回答“是”之前先读懂这份交易，若移除操作动到了你需要的东西就停下来。不读方案而反复修复，正是让一个小小的依赖缺口变成一台再也起不来的桌面的做法。

保留包管理器给出的第一条有意义的报错，并在动手前先分类。未签名的仓库、已配置源中不存在的包、版本冲突、以及能启动随后又退出的客户端，是四种不同的故障。

验证应用，而不是仓库

确认客户端进入已安装状态，再确认程序能够启动。dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop 应当报出带版本的 install ok installed；此后启动失败属于应用问题，而不是打包问题。

把仓库的所有者和应用包记为两个独立对象，这样日后卸载时移除的是正确的那一个，另一个保持完好。厂商改了指南时，你要重读的是源条目；要重装的是客户端名称。