Fedora 46 bascule sur le format de paquets RPM v6, vingt-cinq ans après le v4
Le 16 octobre 2026, l’ingénieur Red Hat Panu Matilainen dépose une proposition pour faire passer Fedora 46 du format RPM v4 au RPM v6, une modernisation « largement invisible » qui préparera la base de RHEL 11. Pour les administrateurs et les mainteneurs de dépôts tiers, c’est le moment de vérifier que leur outillage sait encore lire les en-têtes.
16 octobre 2026. L’ingénieur Red Hat Panu Matilainen dépose une change proposal pour faire basculer Fedora du format de paquets RPM v4 vers RPM v6. Vingt-cinq ans. C’est l’âge du format v4, le socle de Red Hat Enterprise Linux et de Fedora depuis plus de deux décennies. RHEL 11. La prochaine majeure de Red Hat, attendue sur une base proche de Fedora 46, hériterait elle aussi du v6. Pourquoi c’est important : un changement de format de paquet est rarement spectaculaire, mais il conditionne la cryptographie des signatures, les outils de build et la compatibilité de tout l’écosystème de dépôts tiers.
Un « face-lift » pensé pour être invisible
La proposition, soumise au FESCo (le comité d’ingénierie de Fedora), est portée par l’un des mainteneurs historiques de RPM. Son argument tient en une phrase, traduite du texte original : le format v4 « a un quart de siècle, et cela se voit dans des choses comme la cryptographie obsolète, les limitations de taille, etc. » Le v6 est décrit comme « essentiellement un lifting » destiné à éliminer « quelques bizarreries et zones d’ombre ».
Concrètement, le RPM v6 apporte trois corrections structurelles. D’abord, des algorithmes cryptographiques modernes pour les signatures et les condensés, là où le v4 traîne l’héritage de l’ère SHA-1/MD5 — une ère refermée depuis la collision SHAttered de 2017. Ensuite, des tags de taille en 64 bits, qui lèvent les plafonds de métadonnées d’un format pensé à l’époque des disques de quelques gigaoctets. Enfin, des chaînes toujours encodées en UTF-8, ce qui supprime une classe entière d’erreurs de localisation.
Le point le plus instructif est dans le texte lui-même : « la plupart de ces fonctionnalités existent déjà comme extensions du format v4, utilisées silencieusement quand c’est nécessaire ». Autrement dit, le v6 officialise ce que le v4 faisait déjà en cachette, sans casser la lecture des paquets existants. C’est pour cela que la proposition insiste sur un changement « largement invisible pour l’utilisateur moyen » : il s’agit de fiabiliser le socle, pas de le réécrire.
Le vrai enjeu : RHEL 11 et l’écosystème tiers
La modernisation n’est pas qu’une affaire Fedora. Le lien est explicite dans la proposition : RHEL 11 est attendu sur une base correspondant à l’état de Fedora 46, ce qui signifie que le RPM v6 deviendrait aussi le format de la distribution d’entreprise la plus répandue au monde. Le calendrier donne la mesure : Fedora 45 sort « dans environ deux semaines », et Fedora 46 en avril, après le vote du FESCo — un vote que l’annonce juge d’emblée peu susceptible de faire débat.
C’est là que le changement, invisible pour l’utilisateur final, devient visible aux bons endroits : les miroirs, les générateurs de métadonnées comme createrepo_c, les linters comme rpmlint, et surtout les dépôts tiers — COPR, EPEL, RPM Fusion. Leurs paquets devront à terme être empaquetés et signés en v6 sans casser la lecture des versions antérieures. Le même format RPM est partagé par openSUSE et SUSE : ce qui se décide côté Fedora regarde de près toute la famille des distributions à paquets RPM.
Un paquet v6 mal compris par un outil ancien, c’est un dépôt qui échoue silencieusement au moment de la mise à jour. La bascule n’a rien de spectaculaire le jour J — c’est en amont que tout se joue.
La comparaison avec les autres écosystèmes donne du recul. Debian n’a pas changé son format .deb depuis des décennies, et Arch Linux s’en tient à de simples archives compressées rejouables. Fedora est, parmi les grandes distributions, celle qui pousse le plus vite la modernisation de sa chaîne d’empaquetage — et c’est précisément pour cela qu’elle sert de banc d’essai à RHEL 11. Le risque n’est donc pas dans la migration elle-même, réputée sans heurts pour les paquets standards, mais dans la longue traîne des outils qui n’auront pas été testés : un wrapper de signature écrit il y a dix ans, un plugin de miroir, un hook de déploiement qui filtre les en-têtes. C’est cette longue traîne que la sortie de Fedora 45 donne le temps de rattraper.
D’où vient RPM, et pourquoi le v4 a tenu un quart de siècle
RPM est né chez Red Hat au milieu des années 1990, à une époque où installer un logiciel Linux signifiait le plus souvent compiler depuis les sources. Le format v4, lui, s’est stabilisé autour de l’an 2000. S’il a tenu vingt-cinq ans, ce n’est pas par inertie : un format de paquet est un contrat public — chaque outil, chaque miroir, chaque dépôt tiers le parse, et le changer revient à toucher une fondation que des milliers de scripts supposent immuable.
C’est exactement ce que la proposition reconnaît. Les limites du v4 sont connues depuis longtemps : des tags de taille en 32 bits qui plafonnent certaines métadonnées — gênant dès qu’un paquet embarque un modèle d’IA ou un gros jeu de données — des algorithmes de signature qui ont vieilli, et une série d’extensions (compression zstd, condensés SHA-256, signatures Ed25519) ajoutées « silencieusement » au fil des ans. Le v6 rassemble ces rustines dans un format cohérent, et c’est précisément pour cela que la bascule peut rester transparente.
Cette migration s’inscrit dans un mouvement plus large de modernisation du socle Fedora : la distribution est déjà passée à dnf5, la réécriture de son gestionnaire de paquets en C++. Le v6 est la pièce suivante du même puzzle — moderniser la base sans jamais casser la compatibilité que les utilisateurs tiennent pour acquise.
En pratique, l’effort d’adaptation se concentre sur une poignée d’outils plutôt que sur l’utilisateur : createrepo_c pour les métadonnées de dépôt, rpmlint pour la validation, et tout script maison qui lit des tags de requête comme %{NAME} ou les en-têtes. Ce sont ces parseurs qu’il faut tester en premier, pas dnf.
Ce qu’un administrateur doit vérifier dès maintenant
Rien n’est cassé aujourd’hui, et c’est précisément le piège : la bascule se prépare avant la sortie, pas après. Deux vérifications suffisent pour dormir tranquille. La première porte sur les signatures : un rpm -K doit continuer à valider les paquets que vous construisez ou signez vous-même. La seconde porte sur votre outillage de lecture : si un script maison parse les en-têtes avec du code écrit pour le v4, c’est lui qu’il faut mettre à l’épreuve en premier.
# Valider signature et condensés d’un paquet (les algorithmes évoluent en v6)
rpm -K ./mon-paquet.rpm
# Inspecter un en-tête sans installer — à re-tester sur un paquet v6 de test
rpm -qp --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' ./mon-paquet.rpmLa démarche recommandée est simple : dès que Fedora 45 est sortie, construisez un paquet de test en v6 dans un bac à sable et faites-le traverser toute votre chaîne — signature, publication, miroir, installation. Si un maillon casse, il vous reste plusieurs mois avant Fedora 46 et RHEL 11 pour le corriger à froid, sans urgence de production.
Verdict
La recommandation dépend de votre position dans l’écosystème. Si vous êtes utilisateur final, vous n’avez rien à faire : le v6 est conçu pour être transparent, et dnf continuera de fonctionner à l’identique. Si vous maintenez un dépôt tiers, un miroir ou un outil qui lit du RPM, ne traitez pas ce sujet comme une formalité : listez dès maintenant vos parseurs et vos chaînes de signature, et planifiez un paquet de test v6 dans les semaines qui suivent la sortie de Fedora 45. C’est le genre de migration qui ne pardonne pas d’être découverte le jour où RHEL 11 est déjà en production.