റെപോ പാക്കേജോ 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-യോട് ഒരു സ്ഥിരതയുള്ള അവസ്ഥ ആവശ്യപ്പെടുന്നു. ഏത് VPN ആണ് വേണ്ടതെന്ന് APT-ക്ക് അറിയില്ല, അതിന്റെ പ്ലാൻ കണ്ടെത്തിയ നിയന്ത്രണം തൃപ്തിപ്പെടുത്താൻ പാക്കേജുകൾ നീക്കം ചെയ്യാം. അതെ എന്ന് ഉത്തരം നൽകുന്നതിന് മുൻപ് നിർദ്ദേശിച്ച ഇടപാട് വായിക്കുക, നീക്കം ചെയ്യൽ നിങ്ങൾക്ക് വേണ്ട എന്തെങ്കിലും തൊടുന്നുണ്ടെങ്കിൽ നിർത്തുക. പ്ലാൻ വായിക്കാതെ അറ്റകുറ്റപ്പണി ആവർത്തിക്കുന്നതാണ് ചെറിയ ആശ്രിതത്വ വിടവിനെ ഇനി ബൂട്ട് ചെയ്യാത്ത ഡെസ്ക്ടോപ്പാക്കുന്ന വഴി.

പാക്കേജ് മാനേജറുടെ ആദ്യത്തെ അർത്ഥവത്തായ സന്ദേശം സൂക്ഷിക്കുക, പ്രവർത്തിക്കുന്നതിന് മുൻപ് അത് വർഗ്ഗീകരിക്കുക. ഒപ്പിടാത്ത റെപോ, കോൺഫിഗർ ചെയ്ത സ്രോതസ്സുകളിൽ ഇല്ലാത്ത പാക്കേജ്, പതിപ്പ് കൂട്ടിയിടി, തുടങ്ങി മരിക്കുന്ന ക്ലയന്റ് എന്നിവ നാല് വെവ്വേറെ തകരാറുകളാണ്.

ആപ്ലിക്കേഷൻ പരിശോധിക്കുക, റെപോയല്ല

ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്ത അവസ്ഥയിൽ എത്തിയെന്ന് സ്ഥിരീകരിച്ച്, പ്രോഗ്രാം ആരംഭിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop ഒരു പതിപ്പോടെ install ok installed റിപ്പോർട്ട് ചെയ്യണം, അതിന് ശേഷമുള്ള സമാരംഭന പരാജയം പാക്കേജിംഗിന്റെയല്ല, ആപ്ലിക്കേഷന്റെ പ്രശ്നമാണ്.

റെപോ ഉടമയും ആപ്ലിക്കേഷൻ പാക്കേജും വെവ്വേറെ വസ്തുക്കളായി രേഖപ്പെടുത്തുക, പിന്നീടുള്ള നീക്കം ശരിയായത് എടുത്ത് മറ്റേത് കേടുകൂടാതെ വിടാൻ. വെണ്ടർ തന്റെ ഗൈഡ് മാറ്റുമ്പോൾ, സ്രോതസ്സ് എൻട്രിയാണ് നിങ്ങൾ വീണ്ടും വായിക്കുന്നത്; ക്ലയന്റ് പേരാണ് നിങ്ങൾ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നത്.