Пакет репозитория или пакет 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= в строке источника. Ключ в неверном каталоге даёт ошибку неаутентифицированного источника, и это иной сбой, чем недоступный пакет.

Считайте сбой зависимости отдельным этапом

Установка скачанного .deb с помощью dpkg -i ничего не решает: команда проверяет зависимости, сообщает, чего не хватает, и оставляет пакет наполовину настроенным. Это ожидаемое поведение, а не повреждённая загрузка.

Затем apt --fix-broken install просит APT привести систему в согласованное состояние из имеющихся источников. APT не знает, какой VPN вам был нужен, и его план может удалить пакеты, чтобы удовлетворить найденному ограничению. Прочитайте предложенную транзакцию, прежде чем ответить да, и остановитесь, если удаления затрагивают что-то нужное. Повторять исправление, не читая план, — это путь, которым небольшой пробел в зависимостях превращается в рабочий стол, который больше не запускается.

Сохраните первое содержательное сообщение менеджера пакетов и классифицируйте его до действий. Неподписанный репозиторий, пакет, которого нет в настроенных источниках, конфликт версий и клиент, который запускается и затем умирает, — это четыре разных сбоя.

Проверяйте приложение, а не репозиторий

Убедитесь, что клиент достиг установленного состояния, затем убедитесь, что программа запускается. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop должен сообщить install ok installed с версией, а сбой запуска после этого — проблема приложения, а не упаковки.

Записывайте владельца репозитория и пакет приложения как отдельные объекты, чтобы последующее удаление убрало нужное и оставило другое нетронутым. Когда поставщик меняет руководство, вы перечитываете запись источника; имя клиента — это то, что вы переустанавливаете.