Repopaketti vai VPN-asiakaspaketti: kumpi ensin?
Julkaisupaketti rekisteröi vain lähteen ja allekirjoitusavaimen. Päätä, kannattaako toimittajan repo, ja asenna asiakas sitten omana vaiheenaan.
Asennat toimittajan paketin, komento palauttaa nollan, eikä käynnistettävää VPN-sovellusta silti ole. Näin käy, kun asentamasi paketti määritti repon sen sijaan, että olisi toimittanut asiakkaan, ja ero näkyy siinä, mitä paketti jätti levylle. Tarvitsetko molempia ja missä järjestyksessä, riippuu kolmesta ehdosta eikä toimittajan nimeämisestä. Alla oleva päätös pitää lähteen määrityksen, metatietojen päivityksen ja sovelluksen asennuksen erillisinä toimina, joilla on erilliset todisteet.
Mikä kussakin paketissa oikeasti muuttuu
Repon määrityspaketti kirjoittaa APT-lähdemerkinnän, tuo sen merkinnän luottaman allekirjoitusavaimen ja poistuu. Sen sisältö on pari tiedostoa hakemistossa /etc/apt sekä avainrengas, eikä mitään ajettavaa. Asiakaspaketti toimittaa daemonin tai työpöytäsovelluksen, sen kirjastot ja riippuvuudet, ja se on se objekti, joka päätyy valikkoon tai systemd-yksikköön.
-release päättyvät tiedostonimet viittaavat ensimmäiseen tyyppiin, mutta pääte on käytäntö eikä tae. Luotettava väite paketin roolista on sen tiedostoluettelo ja riippuvuudet, ja molemmat ovat luettavissa ennen kuin mitään asennetaan. Toimittaja, joka muotoilee paketointinsa uudelleen, pitää saman tiedostonimen ja vaihtaa sisällön, joten kaksi vuotta vanhasta ketjusta kopioitu vastaus voi kuvata pakettia, jota ei enää ole. Lue palveluntarjoajan nykyiset ohjeet käyttämällesi julkaisulle ja tarkista sitten, mitä paketti ilmoittaa.
Jaosta seuraa kolme vaihetta: rekisteröi lähde, päivitä sen syöttämät metatiedot ja asenna sitten sovellus nimeltä. Debianin ja Ubuntun asennusohje pitää ne erillään, minkä vuoksi asiakas pyydetään myöhemmässä vaiheessa eikä paketissa, joka määritti lähteen.
Kolme ehtoa, jotka ratkaisevat järjestyksen
Ensimmäinen ehto on, julkaiseeko toimittaja repon juuri sinun jakelujulkaisullasi. Yhdelle sarjalle rakennettu lähderivi voi ratketa toisen sarjan riippuvuuksia vasten ja asentaa yhdistelmän, jota kukaan ei testannut.
Toinen on, onko jakelussasi jo asiakas. Kun on, jakelupaketti seuraa julkaisusi kirjastosiirtymiä ja tietoturvapäivityksiä, kun taas toimittajan paketti voi liikkua nopeammin ja tuoda mukanaan omat kopionsa jaetuista kirjastoista.
Kolmas on, mitä ominaisuuksia todella tarvitset. Toimittajan koonti voi toimittaa uudemman protokollatoteutuksen tai työpöytäintegraation, jota jakelusi ei ole paketoinut, ja se on todellinen syy hyväksyä toinen lähde. Jos jakelun koonti kattaa käyttösi, kolmannen osapuolen repon lisääminen ostaa päivitystyötä ja yhden luottamussuhteen lisää hyvin vähällä.
Ratkaise nuo kolme vastausta ennen kuin lähderivi on olemassa, sillä sen poistaminen myöhemmin tarkoittaa paketin ja sen avaimen poistamista. Kun ne on ratkaistu, toimittajan polun sisäinen järjestys ei ole valinta: lähde ensin, metatiedot toiseksi, sovellus kolmanneksi, ei koskaan päinvastoin.
Tarkista, mitä julkaisupaketti jätti jälkeensä
Ennen kuin asennat mitään muuta, lue tiedostoluettelo äläkä kuvausta. Debian-sukuisissa järjestelmissä paketin manifesti vastaa siihen, mitä se määritti ja mihin avain päätyi.
dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/
Ensimmäinen rivi näyttää lähdetiedoston ja avainrenkaan polun, ja toinen kertoo, mitä versiota määritetyt lähteet voivat tarjota. Jos apt-cache policy ei tulosta mitään asiakkaan nimelle, metatietojen päivitystä ei ole tehty tai lähde kohdistuu eri sarjaan. Kolmas vahvistaa, että merkintä on siellä, mistä APT todella lukee.
Sovita avainrenkaan polku lähderivin signed-by=-kenttään. Väärässä hakemistossa oleva avain tuottaa todentamattoman lähteen virheen, joka on eri vika kuin saatavilla olematon paketti.
Käsittele riippuvuusvirhe erillisenä vaiheena
Ladatun .deb-paketin asentaminen komennolla dpkg -i ei ratkaise mitään: se tarkistaa riippuvuudet, ilmoittaa puuttuvat ja jättää paketin puoliksi määritetyksi. Se on odotettu käytös, ei vioittunut lataus.
apt --fix-broken install pyytää sitten APT:lta johdonmukaista tilaa käytettävissä olevista lähteistä. APT ei tiedä, mitä VPN:ää halusit, ja sen suunnitelma voi poistaa paketteja löytämänsä rajoitteen täyttämiseksi. Lue ehdotettu tapahtuma ennen kuin vastaat kyllä, ja pysähdy, jos poistot koskevat jotain tarvitsemaasi. Korjauksen toistaminen suunnitelmaa lukematta on se tapa, jolla pieni riippuvuusaukko muuttuu työpöydäksi, joka ei enää käynnisty.
Pidä paketinhallinnan ensimmäinen merkityksellinen viesti ja luokittele se ennen toimintaa. Allekirjoittamaton repo, paketti jota määritetyt lähteet eivät sisällä, versioristiriita ja asiakas, joka käynnistyy ja sitten kuolee, ovat neljä erillistä vikaa.
Vahvista sovellus, älä repoa
Vahvista, että asiakas saavutti asennetun tilan, ja vahvista sitten, että ohjelma käynnistyy. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop-komennon pitäisi raportoida install ok installed version kanssa, ja sen jälkeinen käynnistysvirhe on sovellusongelma eikä paketointiongelma.
Kirjaa repon omistaja ja sovelluspaketti erillisinä objekteina, jotta myöhempi poisto ottaa oikean etkä jätä toista ehjäksi. Kun toimittaja muuttaa ohjettaan, lähdemerkintä on se, minkä luet uudelleen; asiakkaan nimi on se, minkä asennat uudelleen.