Le vendredi vingt quatre juillet, le développeur Ubuntu Benjamin Drung a écrit à la liste ubuntu-devel pour demander si quelqu'un s'opposait au retrait de /etc/debian_version du paquet base-files. La cible est Ubuntu 26.10, et le bug Launchpad qu'il veut clore a été ouvert en 2005. Le fichier n'a jamais dit la vérité sur Ubuntu : il indique la version de Debian Sid dont les paquets sont issus, et rien sur le système que vous faites réellement tourner. Presque plus personne ne le lit volontairement, et c'est précisément pour cela qu'il faut vérifier, car les endroits qui le lisent encore sont de vieux scripts, des installeurs propriétaires et des images de conteneurs que personne n'a rouvertes depuis des années. Nous avons regardé ce qui casse, et ce qu'il faut chercher.
The short answer
Le développeur Ubuntu Benjamin Drung a demandé à la liste ubuntu-devel, le vingt quatre juillet, si quelqu'un s'opposait au retrait de /etc/debian_version du paquet base-files, avec Ubuntu 26.10 pour cible. Le fichier indique la version de Debian Sid dont viennent les paquets plutôt que quoi que ce soit sur le système en cours, ce que dit le bug Launchpad 19353 depuis 2005. Le remplacement est /etc/os-release, standard depuis une dizaine d'années. Tout ce qui lit encore l'ancien fichier devrait migrer avant qu'une montée de version ne rende la question urgente.
Il existe une catégorie de fichiers qui survivent des décennies parce que les retirer paraît plus risqué que les laisser, alors même que tout le monde s'accorde à dire qu'ils sont faux. Ubuntu en traîne un depuis sa première version, et quelqu'un a fini par proposer d'agir.
La proposition
Benjamin Drung, qui travaille à la fois sur Debian et Ubuntu, a écrit à ubuntu-devel juste après minuit UTC, le vendredi vingt quatre juillet. L'objet était direct : retirer /etc/debian_version de base-files. Le message est une demande d'objections et non l'annonce d'une décision, ce qui est la bonne façon de faire avancer un changement de cette forme.
Son argument tient en peu de mots. Les applications qui lisent encore ce fichier devraient lire /etc/os-release à la place, standard de fait depuis dix ans. La version qu'il vise est Ubuntu 26.10, et le bug qu'il veut clore est le Launchpad 19353, ouvert en 2005 et jamais refermé depuis.
Phoronix a repris l'information le jour même, et c'est ainsi que la plupart des gens en dehors de la liste en ont entendu parler.
Pourquoi ce fichier a toujours été faux sur Ubuntu
Sur Debian, /etc/debian_version fait ce que son nom annonce. Il contient la version Debian, et le lire vous apprend quelque chose de vrai.
Ubuntu hérite du fichier via base-files, le paquet qui fournit l'arborescence de base, et là le sens se défait. Ce qu'il contient, c'est la version de Debian Sid depuis laquelle le jeu de paquets d'Ubuntu a été importé pendant le cycle de développement. C'est un fait sur l'ascendance de l'archive, pas sur la machine. Un système Ubuntu qui annonce un numéro de version Debian testing ne ment pas exactement, mais il répond à une question que personne n'a posée.
Le rapport de bug de 2005 faisait déjà cette remarque quand Ubuntu avait un an. La recommandation qui l'accompagne, répétée sans discontinuer pendant vingt ans, était d'utiliser lsb_release ou /etc/os-release à la place. Les deux existaient, les deux étaient corrects, et le fichier est resté quand même, parce que le coût d'une suppression se paie tout de suite et celui d'une conservation se paie par celui qui s'y perdra ensuite.
Ce qu'il faut lire à la place
/etc/os-release est un fichier clé valeur en syntaxe shell, donc vous pouvez le sourcer plutôt que l'analyser, et il est standard entre distributions depuis assez longtemps pour que sa présence puisse être supposée sans risque.
Les champs qui comptent pour une logique de détection sont ID, qui vous donne ubuntu ou debian comme identifiant exploitable par une machine, VERSION_ID, qui donne 26.04 ou équivalent, VERSION_CODENAME, et PRETTY_NAME pour tout ce que vous comptez montrer à un humain.
ID_LIKE est le champ à connaître si vos scripts ont historiquement utilisé la présence de /etc/debian_version comme test de famille. Sur Ubuntu, il contient debian, c'est à dire exactement le signal que l'ancien test cherchait à obtenir. Tester ID_LIKE sur debian couvre Ubuntu, Mint, Pop et tous les autres dérivés de la famille sans entretenir de liste de noms, et le fait via une interface documentée plutôt qu'un fichier dont le sens était accidentel.
Une habitude mérite d'être corrigée au passage. Sourcer os-release dans un script qui utilise ensuite $NAME ou $VERSION pour son propre compte provoquera une collision, car ce sont des noms de variables courants et le fichier écrasera ce que vous aviez. Sourcez le dans un sous shell, ou lisez uniquement les champs nécessaires sans tirer tout le fichier dans votre espace de noms.
Ce qui risque de casser, et comment le trouver
Le code maintenu activement n'est pas le problème. Tout ce qui a été écrit ou relu depuis dix ans utilise déjà os-release, puisque c'est ce que la documentation recommande sur toute la période.
L'exposition se trouve dans le code que personne n'ouvre. Scripts d'inventaire de parc écrits avant l'existence d'os-release et jamais revus parce qu'ils fonctionnent encore. Installeurs de fournisseurs qui appellent une routine de détection de plateforme, en particulier les agents propriétaires dont vous ne voyez pas la logique. Images de conteneurs avec un test de distribution en haut d'un point d'entrée. Modules de supervision et de gestion de configuration qui font de l'empreinte système, où le test est enfoui dans une bibliothèque plutôt que dans votre propre code.
Le mode de défaillance justifie d'y consacrer quelques minutes plutôt qu'un haussement d'épaules. Un script qui fait test -f /etc/debian_version pour décider s'il est sur un système de la famille Debian n'échoue pas bruyamment quand le fichier disparaît. Il prend l'autre branche, silencieusement, et fait ce qu'il fait pour un système qu'il croit être ni Debian ni Ubuntu. Selon le script, cela donne un mauvais gestionnaire de paquets, une étape de configuration sautée, ou une entrée d'inventaire qui affiche discrètement inconnu.
La recherche par motif constitue tout le plan de remédiation. Cherchez debian_version dans votre dépôt de gestion de configuration, vos Dockerfiles et Containerfiles, et tout répertoire de scripts locaux. Sur les hôtes en production, vous pouvez aussi vérifier empiriquement si quelque chose lit encore le fichier, ce qui transforme une supposition en réponse.
Le calendrier laisse de la marge
Rien n'est à faire aujourd'hui. Il s'agit d'une proposition sur une liste de diffusion, la 26.10 est une version intermédiaire et non une LTS, et une version intermédiaire est exactement là où ce genre de changement doit atterrir pour que les aspérités soient trouvées par des gens qui se sont portés volontaires. Qui est sur une LTS dispose de bien plus de temps.
La raison de regarder tout de suite est que le diagnostic est facile tant que le fichier existe et devient pénible ensuite. Aujourd'hui, vous cherchez, vous trouvez trois scripts, et vous les corrigez en une après midi avec l'ancien comportement encore disponible pour comparaison. Après une montée de version, ces mêmes trois scripts se manifestent sous forme de mauvaise détection quelque part en aval, et il faut remonter depuis le symptôme. Vingt ans, c'est long pour un fichier qui a tort. Vingt minutes pour vérifier que rien chez vous n'en dépendait, c'est peu cher payé.
Sources et pour aller plus loin
- Le message de Benjamin Drung sur ubuntu-devel : retirer /etc/debian_version de base-files
- Phoronix : Ubuntu veut se débarrasser de l'artefact historique /etc/debian_version
- UbuntuHandbook : Ubuntu corrige un bug de vingt ans en retirant /etc/debian_version
- La spécification os-release
Questions fréquentes
Qu'est ce que /etc/debian_version et pourquoi est il faux sur Ubuntu ?
C'est un fichier d'une ligne que Debian fournit pour enregistrer la version Debian du système. Ubuntu en hérite via le paquet base-files, mais sur un système Ubuntu il ne décrit pas Ubuntu du tout : il nomme la version de Debian Sid dont le jeu de paquets a été dérivé à un moment du cycle de développement. Un script qui le lit sur Ubuntu apprend donc quelque chose de vrai sur un instantané Debian et rien de vrai sur la machine devant lui. Ce décalage constitue toute la substance du rapport de bug de 2005.
Que doivent lire les scripts à la place ?
/etc/os-release, standard inter distributions depuis une dizaine d'années et déjà utilisé par tous les outils modernes. C'est un fichier clé valeur compatible shell, donc vous pouvez le sourcer directement et lire ID, VERSION_ID, VERSION_CODENAME et PRETTY_NAME. ID_LIKE est le champ qui compte pour une logique portable, car sur Ubuntu il contient debian, ce qui permet d'écrire une seule branche couvrant toute la famille au lieu d'entretenir une liste de noms de dérivés.
Est ce décidé, ou encore à l'état de proposition ?
Encore une proposition à l'heure où nous écrivons. Le message de Drung est formulé comme une demande d'objections et non comme une annonce, ce qui est la façon normale dont ce genre de changement avance sur ubuntu-devel. Ubuntu 26.10 est la version qu'il a citée comme cible. Voyez y un signal fort sur la direction prise plutôt qu'un événement planifié, et notez qu'une version intermédiaire est justement le bon endroit pour tenter cela, précisément parce que ce n'est pas une LTS.
Qu'est ce qui va réellement casser ?
Rien de ce que vous maintenez activement, très probablement. Le risque se loge dans le code que personne n'a rouvert : scripts d'inventaire de parc écrits avant l'existence d'os-release, installeurs de fournisseurs qui appellent un shell pour détecter la plateforme, images de CI avec un test de distribution en haut de fichier, agents de supervision qui font de l'empreinte système. Le mode de défaillance est en général une mauvaise détection silencieuse plutôt qu'un plantage, car un script qui fait test -f /etc/debian_version pour décider qu'il est sur un système de la famille Debian prendra simplement la mauvaise branche.
Comment trouver le code qui le lit ?
Cherchez debian_version dans votre gestion de configuration, vos définitions de conteneurs et vos répertoires de scripts locaux. Sur un hôte en fonctionnement, vérifier si quoi que ce soit ouvre encore le fichier donne une réponse vivante plutôt qu'une supposition. L'intérêt de le faire maintenant, tant que le fichier existe, est qu'une mauvaise réponse aujourd'hui produit un résultat clair que vous pouvez corriger, alors que la même mauvaise réponse après une montée de version produit une détection erronée qu'il faudra remonter depuis ses symptômes.
Debian conserve t il le fichier ?
Cette proposition porte sur le paquet base-files d'Ubuntu, elle ne retire donc rien à Debian. Mais le raisonnement vaut partout où le fichier est lu, et la cible de migration est la même des deux côtés. Écrire votre détection contre os-release est la réponse portable quelle que soit la distribution où atterrit le script, ce qui rend l'opération intéressante à faire une fois plutôt que distribution par distribution.