URL-ਆਧਾਰਿਤ ਪੈਕੇਜ ਡਾਊਨਲੋਡਾਂ ਲਈ RPM ਪਰਾਕਸੀ ਚੋਣਾਂ

rpm -Uvh https://packages.example.net/example.rpm ਵਿੱਚ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਫੈਚ ਕਰਨ ਦਾ ਪੜਾਅ ਸ਼ਾਮਲ ਹੈ। ਪੈਕੇਜ ਦੀ ਪੁਸ਼ਟੀ ਜਾਂ ਸਥਾਪਨਾ ਤੋਂ ਪਹਿਲਾਂ RPM ਨੂੰ ਫਾਈਲ ਪ੍ਰਾਪਤ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।

ਕੰਮ ਕਰਦੀ DNF ਪਰਾਕਸੀ ਸੰਰਚਨਾ ਉਸ ਵੱਖਰੀ ਕਾਲ ਦੁਆਰਾ ਵਰਤੀਆਂ ਸੈਟਿੰਗਾਂ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੀ। RPM ਦਾ ਮੈਨੂਅਲ ਆਪਣੇ HTTP ਮੁੜ-ਪ੍ਰਾਪਤੀ ਮਾਰਗ ਲਈ --httpproxy ਅਤੇ --httpport ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ। ਸਥਾਪਿਤ RPM ਸੰਸਕਰਣ ਅਤੇ ਇਸਦੇ URL ਸਹਾਇਕ ਦੀ ਬਣਾਵਟ ਵੇਰਵੇ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ। RPM 6 ਦਾ ਆਮ-ਚੋਣ ਸੰਦਰਭ ਇਹਨਾਂ ਨੈੱਟਵਰਕ-ਫੈਚ ਚੋਣਾਂ ਨੂੰ ਬਾਸੀ ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਥਾਂ curl ਜਾਂ GNU Wget ਵਰਗਾ ਸਮਰਪਿਤ ਫੈਚ ਸਾਧਨ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ।

ਤੁਸੀਂ ਜਿਸ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਦੀ ਸੰਭਾਲ ਕਰ ਰਹੇ ਹੋ, ਉਸ ਲਈ ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕਿਹੜੀ ਪਰਤ URL ਫੈਚ ਕਰਦੀ ਹੈ। ਨਵੇਂ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਲਈ, ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਡਾਊਨਲੋਡ ਅਤੇ ਫਿਰ ਸਥਾਨਕ ਪੈਕੇਜ ਪੁਸ਼ਟੀ ਤੇ ਸਥਾਪਨਾ ਇਹਨਾਂ ਬਾਸੀ ਫੈਚ ਚੋਣਾਂ 'ਤੇ ਨਿਰਭਰਤਾ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।

ਖੇਤਰਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਰੱਖੋ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਹਰ ਸੰਸਕਰਣ ਹਰ ਉੱਥੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਾਲਾ URL ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਪਰਾਕਸੀ ਹੋਸਟਨਾਮ ਮੰਗਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿਸੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੀ ਗਲੋਬਲ ਮੈਕਰੋ ਫਾਈਲ ਸੋਧੋ ਨਾ ਕਿ ਕਿਸੇ ਪੁਰਾਣੇ ਜਵਾਬ ਨੇ ਅਜਿਹਾ ਕੀਤਾ ਸੀ।

ਅਸਫਲਤਾ ਦਾ ਪੜਾਅ ਲੱਭੋ: ਕੀ ਫੈਚ ਪਰਾਕਸੀ ਤੱਕ ਪਹੁੰਚ ਸਕਿਆ, ਪ੍ਰਮਾਣੀਕਰਨ ਸਵੀਕਾਰ ਹੋਇਆ, ਅਤੇ ਪੈਕੇਜ ਐਂਡਪੁਆਇੰਟ ਨੇ ਲੋੜੀਂਦੀ ਫਾਈਲ ਵਾਪਸ ਕੀਤੀ? ਬਾਅਦ ਵਿੱਚ ਆਉਣ ਵਾਲੀ ਦਸਤਖ਼ਤ ਜਾਂ ਨਿਰਭਰਤਾ ਗਲਤੀ ਅਟਕੇ ਪਰਾਕਸੀ ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ।

ਆਮ ਪੈਕੇਜ ਪੁਸ਼ਟੀ ਬਣਾਈ ਰੱਖੋ। ਡਾਊਨਲੋਡ ਮਾਰਗ ਨੂੰ ਕੰਮ ਕਰਨਾ ਦਸਤਖ਼ਤ ਜਾਂਚ ਬੰਦ ਕਰਨ, ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੀ ਫਾਈਲ ਸਥਾਪਿਤ ਕਰਨ ਜਾਂ ਸਫਲ DNF ਹੁਕਮ ਨੂੰ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਮੰਨਣ ਦਾ ਕਾਰਨ ਨਹੀਂ ਹੈ ਕਿ ਇਸ RPM ਫੈਚ ਨੇ ਉਹੀ ਮਾਰਗ ਅਪਣਾਇਆ।