저장소 패키지와 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 를 보고해야 하며, 그 뒤의 실행 실패는 패키징이 아니라 프로그램 문제입니다.

저장소 소유자와 프로그램 패키지를 별개의 객체로 기록해 두어, 나중의 제거가 올바른 것을 없애고 다른 하나는 그대로 두게 하십시오. 공급업체가 안내서를 바꾸면 다시 읽는 것은 소스 항목이고, 다시 설치하는 것은 클라이언트 이름입니다.