Nom de la distribution, glibc ou compilateur : ce que l’installateur vérifie

L’installateur affiche « unsupported distribution », vous modifiez une chaîne et il continue jusqu’à échouer une minute plus tard sur une erreur du chargeur. Cette séquence est le symptôme qu’il faut savoir reconnaître : le premier échec était un contrôle de reconnaissance et le second est une limite de compatibilité. Ce sont deux problèmes différents qui se trouvent apparaître dans le même terminal. Modifier le contrôle ne peut que vous faire passer du premier au second.

Le symptôme : l’installateur s’arrête sur votre dérivée

Un script qui lit un nom de distribution et refuse de continuer vous dit que son auteur n’a pas testé votre dérivée. C’est une déclaration de support et non un fait technique, et elle est souvent fausse au sens où le paquet fonctionnerait très bien.

Le problème commence quand le contournement devient le plan. Modifier un fichier d’identité fait passer le contrôle, et le paquet se charge alors, ou ne se charge pas, contre l’environnement d’exécution réellement installé. S’il échoue là, aucune modification d’identité supplémentaire n’aidera.

Le geste utile consiste donc à découvrir quelle question l’installateur a posée, puis à découvrir si la réponse aurait eu de l’importance. Ce sont deux enquêtes distinctes et seule la seconde prédit si le paquet fonctionnera.

Trois versions que l’on appelle la version du système

Une version de distribution nomme un environnement empaqueté. Une version de bibliothèque C nomme une implémentation d’environnement d’exécution et sa version. Une version de compilateur nomme une chaîne d’outils. Dans une conversation, les gens appellent les trois « la version du système », et dans un installateur elles ne sont pas interchangeables.

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

Une application précompilée attend l’environnement d’exécution présent au moment de son édition de liens. Changer les compilateurs sur l’hôte ne la relie pas de nouveau, et une chaîne d’outils plus récente ne change rien aux symboles du chargeur que le binaire demande. L’architecture compte à nouveau séparément, car un paquet 32 bits sur un système 64 bits échoue pour des raisons qu’aucune chaîne de version n’explique.

Gardez les quatre sorties avec le rapport. Les collecter prend dix secondes et elles répondent à la plupart des questions qu’un mainteneur vous poserait autrement par courriel.

Lisez l’erreur, pas le contrôle

La première erreur de lancement est la preuve. Un message sur un objet partagé manquant, ou sur une version de symbole que le chargeur ne peut satisfaire, est un problème de dépendance d’environnement d’exécution. Un message qui répète le nom de la distribution est de nouveau le contrôle de reconnaissance, ailleurs.

La documentation de l’éditeur de liens dynamique décrit comment fonctionne la recherche de bibliothèques et où le chargeur cherche. Changer une étiquette de distribution n’ajoute pas de répertoire à ce chemin de recherche, et c’est pourquoi le second échec semble sans rapport avec le premier.

Ne recourez pas à ldd sur un exécutable téléchargé comme première étape anodine. Son propre manuel avertit qu’il peut exécuter le programme dans certaines circonstances, et exécuter un installateur non fiable est exactement le cas visé par cet avertissement.

Pourquoi modifier la chaîne n’aide pas

Falsifier l’identité du système d’exploitation change la façon dont chaque programme de la machine se voit. Les gestionnaires de paquets, les outils de support et d’autres applications lisent le même fichier, et une valeur qui satisfait un installateur peut en dérouter un autre des mois plus tard.

Remplacer les bibliothèques de l’hôte par des fichiers d’une autre distribution est pire. Cela peut casser des logiciels sans rapport, c’est invisible pour le gestionnaire de paquets, et cela exige un plan de maintenance que personne n’écrit. Ces changements ne sont pas justifiés par un seul installateur restrictif.

Si le contrôle est réellement un défaut de reconnaissance, le mainteneur peut le confirmer et décrire la correction prise en charge. Si ce n’est pas un défaut, la voie prise en charge est une compilation pour votre plateforme, et cette réponse ne change pas parce que la chaîne a été modifiée.

Rédigez un rapport sur lequel le mainteneur peut agir

Notez la distribution et la version, l’architecture, la version du VPN, la condition exacte qui a été refusée et la première erreur d’environnement d’exécution si vous êtes allé jusque-là. Précisez si vous avez modifié quelque chose, car un rapport issu d’un système modifié est un autre rapport.

Laissez l’installateur d’origine inchangé et décrivez le contrôle plutôt que de le contourner. Cette distinction permet au mainteneur de séparer une règle de reconnaissance trop étroite d’une véritable limite de compatibilité binaire, qui sont deux bugs très différents avec deux correctifs très différents.

Si la réponse est que votre plateforme n’est pas prise en charge, c’est un résultat utilisable. Elle vous dit de chercher une compilation prise en charge au lieu de passer une soirée de plus sur des fichiers d’identité qui n’ont jamais été le problème.