Repo Package or VPN Client Package: Which Comes First?

You install the vendor package, the command returns zero, and there is still no VPN application to launch. That happens when the package you installed configured a repository rather than shipping the client, and the difference is visible in what it placed on disk. Whether you need both, and in which order, depends on three conditions rather than on the vendor's naming. The decision below keeps source setup, metadata refresh and application install as separate acts with separate evidence.

What Each Package Actually Changes

A repository-configuration package writes an APT source entry, imports the signing key that entry trusts, and exits. Its payload is a couple of files under /etc/apt plus a keyring, and nothing you can run. A client package ships the daemon or the desktop application, its libraries and its dependencies, and it is the object that ends up in a menu or a systemd unit.

Filenames ending in -release suggest the first kind, but the suffix is a convention rather than a guarantee. The reliable statement about a package's role is its file list and its dependencies, both readable before you install anything. A vendor that reshapes its packaging keeps the same filename and changes the contents, so an answer copied from a two-year-old thread can describe a package that no longer exists. Read the provider's current instructions for the release you run, then check what the package declares.

Three stages follow from that split: register the source, refresh the metadata it feeds, then install the application by name. The Debian and Ubuntu install guide keeps them separate, which is why the client is requested in a later step rather than by the package that set up the source.

Three Conditions That Decide the Order

The first condition is whether the vendor publishes a repository for your exact distribution release. A source line built for one suite can resolve against another suite's dependencies and install a mixture nobody tested.

The second is whether your distribution already carries the client. When it does, the distro package follows your release's library transitions and security updates, while the vendor package may move faster and bring its own copies of shared libraries.

The third is which features you actually need. A vendor build may ship a newer protocol implementation or a desktop integration your distribution has not packaged, and that is a real reason to accept a second source. If the distro build covers your use, adding a third-party repository buys update work and another trust relationship for very little.

Settle those three answers before the source line exists, because removing it later means purging the package and its key. Once they are settled, the sequence inside the vendor path is not a choice: source first, metadata second, application third, never the reverse.

Check What the Release Package Left Behind

Before installing anything else, read the file list instead of the description. On Debian-family systems the package manifest answers what it configured and where the key landed.

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

The first line shows the source file and the keyring path, while the second reports which version the configured sources can offer. If apt-cache policy prints nothing for the client name, the metadata refresh has not happened or the source targets a different suite. The third confirms the entry sits where APT actually reads it.

Match the keyring path against the signed-by= field in the source line. A key in the wrong directory produces an unauthenticated-source error, which is a different fault from an unavailable package.

Treat a Dependency Failure as a Separate Stage

Installing a downloaded .deb with dpkg -i resolves nothing: it checks dependencies, reports what is missing and leaves the package half-configured. That is expected behaviour, not a corrupt download.

apt --fix-broken install then asks APT for a consistent state from the sources you have. APT does not know which VPN you wanted, and its plan can remove packages to satisfy the constraint it found. Read the proposed transaction before answering yes, and stop if the removals touch something you need. Repeating the repair without reading the plan is how a small dependency gap becomes a desktop that no longer starts.

Keep the first meaningful message from the package manager and classify it before acting. An unsigned repository, a package the configured sources do not carry, a version conflict, and a client that starts and then dies are four separate faults.

Verify the Application, Not the Repository

Confirm the client reached the installed state, then confirm the program starts. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop should report install ok installed with a version, and a launch failure after that is an application problem rather than a packaging one.

Record the repository owner and the application package as separate objects, so a later removal takes out the right one and leaves the other intact. When the vendor changes its guide, the source entry is what you re-read; the client name is what you reinstall.