ರೆಪೊ ಪ್ಯಾಕೇಜ್ ಅಥವಾ 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 ಅನ್ನು ಆವೃತ್ತಿಯೊಂದಿಗೆ ವರದಿ ಮಾಡಬೇಕು, ಮತ್ತು ಅದರ ನಂತರದ ಪ್ರಾರಂಭ ವೈಫಲ್ಯ ಪ್ಯಾಕೇಜಿಂಗ್ ಅಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್ ಸಮಸ್ಯೆ.
ರೆಪೊ ಮಾಲೀಕ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ವಸ್ತುಗಳಾಗಿ ದಾಖಲಿಸಿ, ನಂತರದ ತೆಗೆಯುವಿಕೆ ಸರಿಯಾದದ್ದನ್ನು ತೆಗೆದು ಇನ್ನೊಂದನ್ನು ಅಕ್ಷತವಾಗಿ ಬಿಡಲಿ. ಮಾರಾಟಗಾರ ತನ್ನ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಬದಲಿಸಿದಾಗ, ಮೂಲ ನಮೂದು ನೀವು ಮತ್ತೆ ಓದುವುದು; ಕ್ಲೈಂಟ್ ಹೆಸರು ನೀವು ಮತ್ತೆ ಸ್ಥಾಪಿಸುವುದು.