Dans certaines circonstances il est nécessaire qu'une personne autre que le responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de mise à jour est désigné en anglais par l'expression non-maintainer upload (NMU). Dans le présent document, nous traduisons librement cette expression par « mise à jour indépendante ».
Ces mises à jour indépendantes font partie du travail normal des porteurs qui compilent les paquets pour d'autres architectures (voir Le portage, Chapitre 8). Nous faisons aussi des mises à jour indépendantes quand un développeur Debian corrige le paquet d'un autre développeur pour éliminer un trou de sécurité ou un bogue paralysant. Cela se produit plus particulièrement en période de gel de la distribution de développement ou quand le responsable officiel du paquet ne peut pas fournir une correction dans un délai raisonnable.
Ce chapitre contient des informations qui vous expliqueront quand et comment faire des mises à jour indépendantes. Une distinction fondamentale doit être faite entre les mises à jour indépendantes sources et les mises à jour indépendantes binaires. Elle est explicitée dans la section suivante.
Deux nouvelles expressions sont introduites dans cette section : « mise à jour indépendante source » et « mise à jour indépendante binaire ». Ces expressions ont une définition précie dans le monde Debian. Elles correspondent toutes deux au même type d'activité ; elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi nous qualifions ces mises à jours d'indépendantes[13].
Une mise à jour indépendante source est une livraison de paquet faite par une
personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
de corriger un bogue dans le paquet. Une mise à jour indépendante source
implique toujours une modification des sources du paquet, même s'il ne s'agit
que d'un changement dans le fichier debian/changelog. Ce
changement peut tout aussi bien concerner la partie amont du source que la
partie spécifique à Debian. Une mise à jour indépendante source peut aussi
inclure des paquets spécifiques à une architecture, un fichier diff
modifié ou, plus rarement, des nouveaux sources amonts.
Une mise à jour indépendante binaire est la recompilation et l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du résultat d'un effort de portage. Une mise à jour indépendante binaire est la livraison d'un paquet compilé (souvent pour une autre architecture) à condition que cette compilation n'ait pas nécessité de modifications des sources. Dans de nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre compilables sur leur architecture cible ; il s'agira alors d'une mise à jour indépendante source et non d'une mise à jour indépendante binaire. Comme vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à jour indépendantes faites par des porteurs et les autres mises à jour indépendantes.
Les mises à jour indépendantes sources et binaires sont toutes deux couvertes par l'expression « mise à jour indépendante » (NMU[14]). Pourtant cela conduit souvent à des confusions car beaucoup associent « mise à jour indépendante » et « mise à jour indépendante source ». Il faut donc rester vigilant. Dans ce chapitre, si nous utilisons « mise à jour indépendante » seul, il s'agit des deux types de livraisons.
Seuls les responsables Debian officiels peuvent faire des mises à jour indépendantes. Un responsable officiel est une personne dont la clé est dans le porte-clés Debian. Toute personne est invitée à télécharger les paquets sources pour corriger des bogues ; au lieu de faire des mises à jour indépendantes, ils pourront soumettre les rustines qui le méritent au système de suivi des bogues. Les responsables apprécient presque toujours les rustines et les rapports de bogue soignés.
Les recommandations pour déterminer quand faire une mise à jour indépendante source dépendent de la distribution visée (i.e. stable, instable ou experimentale). Les porteurs, ayant une activité particulière, obéissent à des règles légèrement différentes (voir Quand faire une mise à jour indépendante source pour un portage ?, Section 8.2.2).
Quand une faille de sécurité est détectée, un paquet corrigé doit être livré le plus tôt possible. Dans ce cas, un membre de l'équipe de sécurité Debian[15] entrera en contact avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans un délai raisonnable (moins de 48 heures). Si le mainteneur ne peut fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps, l'équipe de sécurité pourra corriger le paquet (i.e. faire une mise à jour indépendante source).
Pendant le cycle de mise au point (release cycle, voir Stable, testing et unstable, Section 5.6.1), les livraisons qui corrigent les bogues de gravité sérieuse (i.e. serious) et supérieures sont encouragées et acceptées. Même pendant cette période, vous devrez tenter d'entrer en contact avec le responsable du paquet ; il pourrait bien être sur le point de livrer un paquet corrigé lui aussi. Comme pour n'importe quelle mise à jour indépendante source, les recommandations de la section Comment faire une mise à jour indépendante source ?, Section 7.4 doivent être respectées.
Les mises à jour indépendantes sont aussi acceptable pour la distribution instable mais seulement en dernier ressort ou avec une autorisation. Essayez d'abord ce qui suit et si cela ne fonctionne pas il est probablement correct de faire une mise à jour indépendante (NMU) :
Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le paquet source, cette mise à jour est automatiquement une mise à jour indépendante source et est soumise aux règles qui suivent. Si un porteur construit un paquet binaire recompilé, les règles sont différentes (voir Instructions pour les mises à jour des porteurs, Section 8.2.
Tout d'abord il est capital que ces mises à jour indépendantes soient aussi peu intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des modules ou des fichiers, ne déplacez pas les répertoires ; plus généralement ne corrigez pas ce qui n'est pas cassé. Faites une rustine aussi petite que possible. Si certaines choses froissent votre sens de l'esthétique, parlez-en au responsable du paquet, au responsable amont ou soumettez un rapport de bogue. Quoiqu'il en soit, les changements esthétiques ne doivent pas être faits lors d'une mise à jour indépendante.
Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit changer, même pour la plus triviale des modifications. Notre système de gestion de paquets s'appuie sur ces numéros de version.
Si vous faites une mise à jour indépendante (NMU), vous devez ajouter
un numéro de version mineur à la partie debian-revision du numéro de
version (la partie qui suit le dernier trait d'union). Ce numéro
supplémentaire débutera à « 1 ». Prenons pour exemple le paquet
« foo » qui porte le numéro de version 1.1-3. Dans l'archive, le
fichier de contrôle du paquet source serait foo_1.1-3.dsc. La
version amont est « 1.1 » et la révision Debian est « 3 ».
La mise à jour indépendante suivante ajouterait le numéro de version mineur
« .1 » au numéro de révision Debian; le nouveau fichier de contrôle
du paquet source serait alors foo_1.1-3.1.dsc.
Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro de version au responsable officiel du paquet, ce qui pourrait perturber son travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas été livré par le responsable officiel.
S'il n'y a pas de partie debian-revision dans le numéro de version
du paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
fasse une livraison basée sur une nouvelle version amont, cette personne doit
choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
paquet doit, lui, démarrer sa numérotation à « 1 ». Notez que pour
faire cela vous devrez utiliser dpkg-buildpackage avec l'option
-sa pour le forcer à utiliser le nouveau paquet source (par défaut
il reconnaît les numéros de révisions « 0 » ou « 1 »
— il n'est pas suffisamment intelligent pour reconnaître
« 0.1 »).
Attention, les porteurs qui ne font que recompiler les paquets pour d'autres architectures n'ont pas besoin de renuméroter les paquets. Les porteurs ne doivent utiliser de nouveaux numéros de version que s'ils modifient les paquets sources qu'ils recompilent, c'est-à-dire s'ils font une mise à jour indépendante source et non une mise à jour indépendante binaire.
Une personne qui fait une mise à jour indépendante source doit ajouter une
entrée dans le fichier changelog qui indique les bogues corrigés
et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
version livrée.
Par convention, dans le cas d'une mise à jour indépendante source (NMU), l'entrée du fichier changelog débute par la ligne
* Non-maintainer upload
Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de modifications que possible et doit toujours envoyer ses modifications au système de suivi des bogues au format diff unifié (diff -u).
En cas de simple recompilation du paquet, le processus diffère suivant que vous
agissez en tant que porteur ou pas. Si vous faites une mise à jour
indépendante qui ne nécessite rien de plus qu'une recompilation et n'agissez
pas en temps que porteur (i.e. une nouvelle bibliothèque partagée est
disponible, un bogue a été corrigé dans debhelper), vous devez
tout de même ajouter une entrée dans le fichier changelog; il y aura
donc une modification. Si vous êtes porteur, vous êtes probablement en train
de faire une mise à jour indépendante binaire. (Note : ce système ne
tient pas compte des porteurs qui font des recompilations — tenez cela
pour une faiblesse de notre système de gestion des paquets.)
Si la mise à jour indépendante source (source NMU) corrige des bogues, ceux-ci doivent être marqués fixed (corrigé) dans le système de suivi des bogues plutôt que clos. Par convention, seul le responsable du paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce rapport. Heureusement, le système d'archivage Debian reconnait les mises à jours indépendantes et positionne correctement le statut des bogues à fixed si la personne qui fait la mise à jour a listé tous les bogues dans le fichier changelog en utilisant la syntaxe Closes: bug#nnnnn (voir Quand les rapports sont fermés par une mise à jour, Section 10.4 pour en savoir plus sur la fermeture de bogue par le fichier changelog). Ce passage au statut fixed assure que chacun sait que le bogue est corrigé par une mise à jour indépendante tout en laissant le rapport de bogue ouvert jusqu'à ce que le responsable du paquet incorpore les modifications de cette mise à jour dans la version officielle du paquet.
Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un nouveau rapport de bogue qui inclura une rustine contenant toutes les modifications que vous avez faites. Le responsable officiel pourra choisir d'appliquer la rustine, il pourra aussi employer une autre méthode pour régler le problème. Certains bogues sont corrigés dans la version amont, ce qui est une bonne raison pour annuler les modifications d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le paquet plutôt que d'utiliser les rustines de la mise à jour indépendante, il devra s'assurer que cette nouvelle version corrige effectivement chacun des bogues corrigés dans la mise à jour indépendante.
De plus, le responsable officiel devrait toujours conserver les
entrées documentant une mise à jour indépendante dans le fichier
changelog.
Les paquets faisant l'objet d'une mise à jour indépendante source sont construits comme les autres. Sélectionnez une distribution en utilisant les règles décrites dans la section Choisir une distribution, Section 6.3.2 et construisez un fichier .changes classique avec tout ce qui l'accompagne conformément à la description Mettre à jour un paquet, Section 6.4.
En fait, toutes les prescriptions de la section La mise à jour d'un paquet, Chapitre 6 sont applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste idoine.
Vérifiez que vous n'avez pas modifié la valeur du champ maintainer
dans le fichier debian/control. Votre nom, mentionné dans
l'entrée du fichier debian/changelog concernant la mise à jour,
sera utilisé pour signer le fichier .changes.
Référence du développeur Debian
Version 2.11, 08 avril 2002 (version française 20020315).aph@debian.orgschwarz@debian.orgijackson@gnu.ai.mit.eduantoine.hulin@origan.fdn.orgdebian-l10n-french@lists.debian.org