Repopaket eller VPN-klientpaket: vilket kommer först?

Du installerar leverantörens paket, kommandot returnerar noll och det finns fortfarande ingen VPN-applikation att starta. Det händer när paketet du installerade konfigurerade ett repo i stället för att leverera klienten, och skillnaden syns i vad det lämnade på disken. Om du behöver båda, och i vilken ordning, beror på tre villkor och inte på leverantörens namngivning. Beslutet nedan håller källkonfiguration, uppdatering av metadata och installation av programmet som separata handlingar med separata bevis.

Vad varje paket faktiskt ändrar

Ett repokonfigurationspaket skriver en APT-källpost, importerar signeringsnyckeln som posten litar på och avslutar. Innehållet är ett par filer under /etc/apt plus en nyckelring, och inget körbart. Ett klientpaket levererar daemonen eller skrivbordsprogrammet, dess bibliotek och beroenden, och det är objektet som hamnar i en meny eller i en systemd-enhet.

Filnamn som slutar på -release antyder den första typen, men ändelsen är en konvention, inte en garanti. Det tillförlitliga påståendet om ett pakets roll är dess fillista och beroenden, och båda är läsbara innan du installerar något. En leverantör som formar om sin paketering behåller samma filnamn och ändrar innehållet, så ett svar kopierat från en två år gammal tråd kan beskriva ett paket som inte längre finns. Läs leverantörens aktuella instruktioner för den utgåva du kör och kontrollera sedan vad paketet deklarerar.

Tre steg följer av den uppdelningen: registrera källan, uppdatera metadatan den matar och installera sedan programmet vid namn. Installationsguiden för Debian och Ubuntu håller dem åtskilda, och därför begärs klienten i ett senare steg och inte av paketet som satte upp källan.

Tre villkor som avgör ordningen

Det första villkoret är om leverantören publicerar ett repo för exakt din distributionsutgåva. En källrad byggd för en svit kan lösas mot en annan svits beroenden och installera en blandning som ingen har testat.

Det andra är om din distribution redan har klienten. När den har det följer distributionspaketet din utgåvas biblioteksövergångar och säkerhetsuppdateringar, medan leverantörens paket kan röra sig snabbare och ta med egna kopior av delade bibliotek.

Det tredje är vilka funktioner du faktiskt behöver. Ett leverantörsbygge kan leverera en nyare protokollimplementering eller en skrivbordsintegration som din distribution inte har paketerat, och det är en verklig anledning att acceptera en andra källa. Om distributionsbygget täcker din användning köper ett tredjepartsrepo uppdateringsarbete och ytterligare en förtroenderelation för mycket lite.

Avgör de tre svaren innan källraden finns, för att ta bort den senare innebär att rensa paketet och dess nyckel. När de är avgjorda är ordningen inom leverantörsspåret inte ett val: källa först, metadata andra, program tredje, aldrig tvärtom.

Kontrollera vad utgivningspaketet lämnade efter sig

Innan du installerar något annat, läs fillistan i stället för beskrivningen. På system i Debian-familjen svarar paketmanifestet på vad det konfigurerade och var nyckeln landade.

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

Den första raden visar källfilen och sökvägen till nyckelringen, medan den andra rapporterar vilken version de konfigurerade källorna kan erbjuda. Om apt-cache policy inte skriver ut något för klientnamnet, har metadatauppdateringen inte skett eller så riktar källan in sig på en annan svit. Den tredje bekräftar att posten sitter där APT faktiskt läser.

Jämför sökvägen till nyckelringen med fältet signed-by= i källraden. En nyckel i fel katalog ger ett fel om oautentiserad källa, vilket är ett annat fel än ett otillgängligt paket.

Behandla ett beroendefel som ett eget steg

Att installera ett nedladdat .deb med dpkg -i löser ingenting: det kontrollerar beroenden, rapporterar vad som saknas och lämnar paketet halvkonfigurerat. Det är förväntat beteende, inte en skadad nedladdning.

apt --fix-broken install ber sedan APT om ett konsekvent tillstånd från de källor du har. APT vet inte vilken VPN du ville ha, och dess plan kan ta bort paket för att uppfylla den begränsning den hittade. Läs den föreslagna transaktionen innan du svarar ja, och stoppa om borttagningarna rör något du behöver. Att upprepa reparationen utan att läsa planen är hur en liten beroendeklyfta blir ett skrivbord som inte startar längre.

Spara det första meningsfulla meddelandet från pakethanteraren och klassificera det innan du agerar. Ett osignerat repo, ett paket som de konfigurerade källorna inte har, en versionskonflikt och en klient som startar och sedan dör är fyra olika fel.

Verifiera programmet, inte repot

Bekräfta att klienten nådde det installerade tillståndet och bekräfta sedan att programmet startar. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop bör rapportera install ok installed med en version, och ett startfel efter det är ett programproblem och inte ett paketeringsproblem.

Registrera repots ägare och programpaketet som separata objekt, så att en senare borttagning tar rätt och lämnar det andra intakt. När leverantören ändrar sin guide är källposten det du läser om; klientnamnet är det du installerar om.