Пакет репозиторію чи пакет 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 з версією, а збій запуску після цього — проблема програми, а не пакування.

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