Deponeja pako aŭ VPN-klienta pako: kiu venas unue?
Eldonpako nur registras fonton kaj subskriban ŝlosilon. Decidu, ĉu la deponejo de la vendisto indas la penon, poste instalu la klienton kiel apartan paŝon.
Vi instalas la pakon de la vendisto, la komando redonas nulon, kaj ankoraŭ ne estas VPN-aplikaĵo por lanĉi. Tio okazas kiam la pako, kiun vi instalis, agordis deponejon anstataŭ liveri la klienton, kaj la diferenco videblas en tio, kion ĝi metis sur la diskon. Ĉu vi bezonas ambaŭ, kaj en kiu ordo, dependas de tri kondiĉoj, ne de la nomado de la vendisto. La decido sube tenas fontagordon, refreŝigon de metadatenoj kaj instaladon de la aplikaĵo kiel apartajn agojn kun apartaj pruvoj.
Kion ĉiu pako efektive ŝanĝas
Deponeja agorda pako skribas APT-fontan enskribon, importas la subskriban ŝlosilon, kiun tiu enskribo fidas, kaj finiĝas. /etc/apt Ĝia enhavo estas kelkaj dosieroj kaj ŝlosilaro, kaj nenio, kion vi povas ruli. Klienta pako liveras la demonon aŭ la labortablan aplikaĵon, ĝiajn bibliotekojn kaj dependecojn, kaj ĝi estas la objekto, kiu finiĝas en menuo aŭ en systemd-unuo.
Dosiernomoj finiĝantaj per -release indikas la unuan specon, sed la sufikso estas konvencio, ne garantio. La fidinda aserto pri la rolo de pako estas ĝia dosierlisto kaj ĝiaj dependecoj, ambaŭ legeblaj antaŭ ol vi instalas ion ajn. Vendisto, kiu reformas sian pakadon, konservas la saman dosiernomon kaj ŝanĝas la enhavon, do respondo kopiita el dujara fadeno povas priskribi pakon, kiu jam ne ekzistas. Legu la aktualajn instrukciojn de la provizanto por la eldono, kiun vi rulas, poste kontrolu, kion la pako deklaras.
El tiu disigo sekvas tri stadioj: registru la fonton, refreŝigu la metadatenojn, kiujn ĝi nutras, poste instalu la aplikaĵon laŭnome. La instala gvidilo por Debian kaj Ubuntu tenas ilin apartaj, tial la kliento petatas en posta paŝo, ne de la pako, kiu agordis la fonton.
Tri kondiĉoj, kiuj decidas la ordon
La unua kondiĉo estas, ĉu la vendisto publikigas deponejon por via ekzakta distribua eldono. Fontlinio konstruita por unu eldono povas solviĝi kontraŭ la dependecoj de alia eldono kaj instali miksaĵon, kiun neniu testis.
La dua estas, ĉu via distribuo jam portas la klienton. Kiam ĝi portas, la distribua pako sekvas la bibliotekajn transirojn kaj sekurecajn ĝisdatigojn de via eldono, dum la vendista pako povas moviĝi pli rapide kaj alporti proprajn kopiojn de komunaj bibliotekoj.
La tria estas, kiujn trajtojn vi efektive bezonas. Vendista konstruo povas liveri pli novan protokolan efektivigon aŭ labortablan integriĝon, kiun via distribuo ne pakis, kaj tio estas reala kialo akcepti duan fonton. Se la distribua konstruo kovras vian uzon, aldoni triapartan deponejon aĉetas ĝisdatigan laboron kaj ankoraŭ unu fidan rilaton por tre malmulte.
Solvu tiujn tri respondojn antaŭ ol la fontlinio ekzistas, ĉar forigi ĝin poste signifas purigi la pakon kaj ĝian ŝlosilon. Post kiam ili solviĝis, la sinsekvo ene de la vendista vojo ne estas elekto: fonto unue, metadatenoj due, aplikaĵo trie, neniam inverse.
Kontrolu, kion la eldonpako postlasis
Antaŭ ol instali ion alian, legu la dosierliston anstataŭ la priskribon. Sur sistemoj de la Debian-familio la pakmanifesto respondas, kion ĝi agordis kaj kie la ŝlosilo surteriĝis.
dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/
La unua linio montras la fontan dosieron kaj la vojon de la ŝlosilaro, dum la dua raportas, kiun version la agorditaj fontoj povas proponi. Se apt-cache policy preskas nenion por la klienta nomo, la metadatenoj ne refreŝiĝis aŭ la fonto celas alian eldonon. La tria konfirmas, ke la enskribo staras tie, kie APT efektive legas.
Kongruigu la vojon de la ŝlosilaro kun la kampo signed-by= en la fontlinio. Ŝlosilo en la malĝusta dosierujo produktas eraron pri neaŭtentikigita fonto, kio estas alia fuŝo ol nehavebla pako.
Traktu dependecan fiaskon kiel apartan stadion
Instalado de elŝutita .deb per dpkg -i solvas nenion: ĝi kontrolas dependecojn, raportas, kio mankas, kaj lasas la pakon duone agordita. Tio estas atendata konduto, ne difektita elŝuto.
apt --fix-broken install poste petas de APT konsekvencan staton el la fontoj, kiujn vi havas. APT ne scias, kiun VPN vi volis, kaj ĝia plano povas forigi pakojn por plenumi la trovitan limigon. Legu la proponitan transakcion antaŭ ol respondi jes, kaj haltu, se la forigoj tuŝas ion, kion vi bezonas. Ripeti la riparon sen legi la planon estas kiel malgranda dependeca breĉo fariĝas labortablo, kiu jam ne startas.
Konservu la unuan signifoplenan mesaĝon de la pakmastrumilo kaj klasifiku ĝin antaŭ ol agi. Nepriskribita deponejo, pako, kiun la agorditaj fontoj ne portas, versia konflikto kaj kliento, kiu startas kaj poste mortas, estas kvar apartaj fuŝoj.
Kontrolu la aplikaĵon, ne la deponejon
Konfirmu, ke la kliento atingis la instalitan staton, poste konfirmu, ke la programo startas. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop devus raporti install ok installed kun versio, kaj lanĉa fiasko post tio estas aplikaĵa problemo, ne pakada.
Registru la deponejan posedanton kaj la aplikaĵan pakon kiel apartajn objektojn, por ke posta forigo prenu la ĝustan kaj lasu la alian sendifekta. Kiam la vendisto ŝanĝas sian gvidilon, la fonta enskribo estas tio, kion vi relegas; la klienta nomo estas tio, kion vi reinstalas.