Options de proxy RPM pour les téléchargements de paquets par URL

rpm -Uvh https://packages.example.net/example.rpm comporte une étape de récupération réseau. Avant la vérification ou l'installation du paquet, RPM doit obtenir le fichier.

Une configuration de proxy DNF qui fonctionne n'établit pas les réglages utilisés par cette invocation distincte. Le manuel de RPM documente --httpproxy et --httpport pour son chemin de récupération HTTP. La version installée de RPM et l'organisation de son assistant d'URL déterminent les détails. La référence des options communes de RPM 6 marque ces options de récupération réseau comme obsolètes et recommande à la place un outil de récupération dédié, comme curl ou GNU Wget.

Pour un flux de travail que vous maintenez, établissez d'abord quelle couche récupère l'URL. Pour un nouveau flux, un téléchargement explicitement approuvé suivi d'une vérification et d'une installation locales du paquet évite de dépendre de ces options de récupération obsolètes.

Conservez les champs dans leur format documenté. Ne supposez pas que chaque version accepte une URL porteuse d'identifiants partout où un nom d'hôte de proxy est demandé, et ne modifiez pas le fichier de macros global d'une distribution simplement parce qu'une ancienne réponse l'a fait.

Identifiez l'étape de l'échec : la récupération a-t-elle pu atteindre le proxy, l'authentification a-t-elle été acceptée et le point de terminaison du paquet a-t-il renvoyé le fichier voulu ? Une erreur ultérieure de signature ou de dépendances est un problème différent d'une connexion proxy bloquée.

Préservez la vérification normale des paquets. Faire fonctionner la route de téléchargement n'est pas une raison pour désactiver les contrôles de signature, installer un fichier non fiable ou considérer une commande DNF réussie comme la preuve que cette récupération RPM a suivi la même route.