Guide de référence pour Debian

Équipe du guide de référence pour Debian <developers-reference@packages.debian.org>

• Copyright © 2019 - 2023 Holger Levsen

• Copyright © 2015 - 2020 Hideki Yamane

• Copyright © 2008 - 2015 Lucas Nussbaum

• Copyright © 2004 - 2007 Andreas Barth

• Copyright © 2002 - 2009 Raphaël Hertzog

• Copyright © 1998 - 2003 Adam Di Carlo

• Copyright © 1997 - 1998 Christian Schwarz

Ce manuel est un logiciel libre; vous pouvez le redistribuer et le modifier selon les termes de la Licence Publique Générale GNU telle que l'a publiée la Free Software Foundation (fondation pour le logiciel libre), soit selon la version2, soit (à votre choix) selon toute autre version ultérieure.

Il est distribué dans l'espoir qu'il sera utile, mais sans aucune garantie; sans même une garantie implicite de qualité loyale et marchande ni aptitude à un quelconque usage. Voyez la Licence Publique Générale GNU pour plus de détails.

Une copie de la Licence Publique Générale GNU est disponible dans /usr/share/common-licenses/GPL-2 dans la distribution Debian ou sur le World Wide Web sur le site Web de GNU. Vous pouvez aussi l'obtenir en écrivant à la Free Software Foundation, Inc., 51Franklin Street, Fifth Floor, Boston, MA02110-1301, USA.

Ceci est la version 13.15, publiée le 2024-11-04, du guide de référence du développeur pour Debian.

Si vous souhaitez imprimer ce guide, vous devriez utiliser la version PDF. Ce manuel est aussi disponible dans d'autres langues.

1. Portée de ce document

Le but de ce document est de fournir une vue d'ensemble des procédures recommandées et des ressources disponibles pour les développeurs et les responsables de paquet de Debian.

Les procédures traitées dans ce document incluent comment devenir un membre du projet (Candidater pour devenir membre du projet), comment créer un nouveau paquet (Nouveaux paquets) et l'envoyer (Envois de paquets), comment manipuler un rapport de bogue (Manipulation des bogues), comment déplacer, supprimer ou abandonner un paquet (Manipulation de paquet dans l'archive), comment porter des paquets (Portage) et enfin, comment et quand effectuer une publication intermédiaire de paquets d'autres responsables (Mises à jour indépendantes (NMU)).

Ce manuel présente entre autres les listes de diffusion (Listes de diffusion) et les serveurs (Serveurs Debian), la structure de l'archive Debian (Archive Debian), des explications sur les serveurs qui acceptent l'envoi de paquets (Envois sur ftp-master) et une présentation des outils qui peuvent aider un responsable à améliorer la qualité de ses paquets (Aperçu des outils du responsable Debian).

Ce manuel de référence ne présente pas les aspects techniques liés aux paquets Debian, ni comment les créer. Il ne décrit pas non plus les règles que doivent respecter les paquets Debian. Ces informations sont disponibles dans la Charte Debian.

De plus ce document n'est pas l'expression d'une politique officielle. Il contient de la documentation sur le système Debian et des conseils pratiques largement suivis. Ce n'est donc pas une sorte de guide de normes.

2. Candidater pour devenir membre du projet

2.1. Entrée en matière

Vous avez lu toute la documentation, vous avez examiné le guide du nouveau responsable (ou son successeur, Guide for Debian Maintainers), vous comprenez l'intérêt de tout ce qui se trouve dans le paquet d'exemple hello et vous vous apprêtez à empaqueter votre logiciel préféré. Comment en pratique devenir responsable Debian et intégrer votre travail au projet ?

Si vous ne l'avez pas encore fait, commencez par vous inscrire à la liste debian-devel@lists.debian.org. Pour cela, envoyez un courriel à debian-devel-REQUEST@lists.debian.org avec le mot subscribe en objet (champ Subject). En cas de problème, contactez l'administrateur de la liste listmaster@lists.debian.org. Vous trouverez plus d'informations en Listes de diffusion. debian-devel-announce@lists.debian.org est une autre liste incontournable pour suivre les développements de Debian.

Vous devriez vous inscrire et suivre les discussions de cette liste (sans poster) pendant quelque temps avant de coder quoi que ce soit, puis vous informerez la liste de votre intention de travailler sur quelque chose pour éviter de dupliquer le travail d'un autre.

Une autre liste intéressante est debian-mentors@lists.debian.org. Voir Mentors et parrains Debian pour les détails. Le canal IRC #debian pourra aussi être utile ; voir Canaux IRC.

Une fois choisie une façon de contribuer au projet Debian, vous devriez entrer en contact avec les responsables Debian qui travaillent sur des tâches similaires. Ainsi, vous pourrez apprendre auprès de personnes expérimentées. Si, par exemple, vous voulez empaqueter des logiciels existants, trouvez-vous un parrain. Un parrain est une personne qui travaillera sur vos paquets avec vous et les enverra dans l'archive Debian une fois satisfait de l'empaquetage. Pour trouver un parrain, envoyez une demande de parrainage à la liste debian-mentors@lists.debian.org en vous présentant et en décrivant votre paquet (voir Parrainage de paquets et https://wiki.debian.org/DebianMentorsFaq pour en savoir plus sur le sujet). Si vous préférez porter Debian sur une architecture ou un noyau alternatif, abonnez-vous aux listes dédiées au portage et demandez-y comment démarrer. Finalement, si vous êtes intéressé par la documentation ou l'assurance qualité (QA), contactez les responsables qui travaillent déjà sur ces tâches et proposez des correctifs et des améliorations.

One pitfall could be a too-generic local part in your email address: Terms like mail, admin, root, master should be avoided, please see https://www.debian.org/MailingLists/ for details.

2.2. Mentors et parrains Debian

La liste de diffusion debian-mentors@lists.debian.org a été mise en place pour les responsables débutants recherchant de l'aide avec l'empaquetage initial et d'autres problèmes de développeur. Chaque nouveau développeur est invité à s'abonner à cette liste (voir Listes de diffusion pour les détails).

Ceux qui préfèrent recevoir une aide plus personnalisée (par exemple, par courrier privé) devraient également envoyer des messages à cette liste et un développeur expérimenté se proposera de les aider.

De plus, si vous avez des paquets prêts à être inclus dans Debian, mais que vous attendez que votre demande pour devenir responsable soit acceptée, vous pouvez trouver un parrain pour envoyer vos paquets pour vous. Les parrains sont des développeurs Debian officiels qui sont volontaires pour critiquer et envoyer vos paquets pour vous. Veuillez lire en premier la FAQ de debian-mentors à https://wiki.debian.org/DebianMentorsFaq.

Pour devenir mentor ou parrain, plus d'informations sont disponibles en Interaction avec de futurs développeurs Debian.

2.3. Enregistrement comme responsable Debian

Avant de décider de devenir responsable Debian, il vous faudra lire toute la documentation disponible dans le coin du nouveau responsable. Elle décrit en détail toutes les étapes préparatoires qu'il vous faudra franchir avant de déposer votre candidature. Par exemple, avant d'être candidat, il vous faudra lire le contrat social Debian. Devenir responsable Debian implique que vous adhériez à ce contrat social et que vous vous engagiez à le soutenir ; il est très important que les responsables soient en accord avec les principes fondamentaux qui animent le projet Debian. Lire le Manifeste GNU est aussi une bonne idée.

Le processus d'enregistrement a pour but de vérifier votre identité, vos intentions et vos compétences. Comme le nombre de personnes travaillant pour Debian a dépassé 1000 et que notre système est utilisé dans plusieurs endroits très importants, nous devons rester vigilants pour éviter un acte malveillant. C'est pourquoi nous contrôlons les nouveaux responsables avant de leur donner un compte sur nos serveurs et de les autoriser à ajouter des paquets dans l'archive.

Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs par le système de suivi des bogues (BTS) et maintenir un paquet parrainé par un responsable Debian pendant un temps. Nous attendons aussi des contributeurs qu'ils soient intéressés par le projet dans son ensemble et pas uniquement par leurs propres paquets. Si vous pouvez aider d'autres responsables en fournissant des informations sur un bogue ou même avec un correctif, faites-le !

Pour votre candidature, vous devrez être familiarisé avec la philosophie du projet Debian et avec sa documentation technique. Il vous faudra aussi une clé OpenPGP signée par un développeur Debian. Si votre clé OpenPGP n'est pas encore signée, vous devriez essayer de rencontrer un développeur responsable Debian pour le faire. La page de coordination des signatures de clé devrait aider à trouver un responsable Debian près de chez vous. (S'il n'y a pas de développeur près de chez vous, des moyens alternatifs existent pour valider votre identité en tant que cas de force majeure étudié au cas par cas. Reportez-vous à la page d'identification pour en savoir plus.)

Si vous n'avez pas de clé OpenPGP, créez-la. Tout développeur a besoin d'une clé OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la documentation du logiciel de cryptographie que vous utiliserez car elle contient des informations indispensables pour la sécurité de votre clé. Les défaillances de sécurité sont bien plus souvent dues à des erreurs humaines qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir Gestion de clé publique pour plus d'informations sur la gestion de votre clé publique.

Debian uses the GNU Privacy Guard (package gnupg version 2 or better) as its baseline standard. You can use some other implementation of OpenPGP as well. Note that OpenPGP is an open standard based on RFC 9580.

La longueur de votre clé doit être d'au moins 2048 bits (de préférence 4096 bits). Il n'y a pas de raison d'utiliser une clé plus petite et le faire serait bien moins sûr.

Si votre clé publique n'est pas sur un serveur public tel que subkeys.pgp.net, reportez-vous à la documentation disponible à l'Étape 2 : Vérification d'identité. Cette documentation explique comment placer votre clé publique sur un serveur. L'équipe en charge des nouveaux responsables placera votre clé publique sur les serveurs de clés si elle n'y est pas déjà.

Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il peut être tout à fait légal d'utiliser des logiciels de cryptographie pour l'authentification plutôt que pour le chiffrement. Si vous vivez dans un pays où l'utilisation de la cryptographie pour l'authentification est interdite, contactez-nous pour que nous prenions des dispositions particulières.

Pour faire acte de candidature, il vous faut un responsable Debian qui soutienne votre candidature (un intercesseur ou advocate en anglais). Après avoir contribué au projet Debian pendant quelque temps, quand vous choisissez de devenir un responsable Debian officiel, un responsable déjà enregistré avec qui vous aurez travaillé dans les derniers mois devra exprimer que, d'après lui, vous pouvez contribuer avec succès au projet Debian.

Une fois trouvé un intercesseur, votre clé OpenPGP signée et que vous avez déjà contribué au projet, vous êtes prêt à faire acte de candidature. Il vous suffit pour cela de vous enregistrer sur la page de candidature. Ensuite, votre intercesseur devra confirmer votre candidature. Quand il aura accompli cette tâche, un responsable de candidature (application manager) sera désigné pour vous accompagner dans le processus d'enregistrement. Vous pouvez toujours consulter le tableau de bord des candidatures pour connaître l'état de votre candidature.

Pour plus de détails, consultez le coin des nouveaux membres Debian sur le site web de Debian. Assurez-vous de bien connaître les différentes étapes nécessaires au processus du nouveau membre avant de vous porter candidat. Si vous êtes bien préparé, vous gagnerez beaucoup de temps plus tard.

3. Devoirs du développeur Debian

3.1. Devoirs du responsable de paquet

En tant que responsable de paquet, vous êtes censé fournir des paquets de haute qualité qui s'intégreront correctement dans le système et qui sont conformes à la Charte Debian.

3.1.1. Œuvrer pour la prochaine publication stable

Fournir des paquets de haute qualité dans unstable ne suffit pas, la plupart des utilisateurs ne profiteront de vos paquets que quand ils seront publiés avec la prochaine version stable. Vous êtes donc censé collaborer avec l'équipe en charge de la publication pour veiller à ce que vos paquets soient intégrés.

Plus concrètement, vous devriez surveiller si vos paquets migrent vers testing (consultez La distribution testing). Lorsque la migration n'a pas lieu après la période d'essai, vous devriez analyser pourquoi et œuvrer pour corriger cela. Votre paquet pourrait avoir besoin d'être corrigé (dans le cas de bogues critiques pour la publication ou d'échecs de construction sur certaines architectures) mais cela peut également signifier mettre à jour (ou corriger, ou supprimer de testing) d'autres paquets pour permettre de terminer une transition dans laquelle votre paquet est enchevêtré à cause de ses dépendances. L'équipe en charge de la publication devrait pouvoir vous renseigner sur ce qui bloque actuellement une transition donnée si vous ne parvenez pas à l'identifier.

3.1.2. Maintenance de paquets dans stable

La plupart du travail de responsable de paquet consiste à fournir des versions de paquets mis à jour dans unstable, mais son travail implique aussi de s'occuper des paquets dans la publication stable actuelle.

Même si les modifications dans stable sont déconseillées, elles sont possibles. Chaque fois qu'un problème de sécurité est signalé, vous devriez collaborer avec l'équipe en charge de la sécurité pour fournir une version corrigée (consultez Gestion des bogues de sécurité). Quand des bogues de sévérité important (ou plus) sont soumis sur la version stable de vos paquets, vous devriez envisager la possibilité de fournir une correction spécifique. Vous pouvez interroger l'équipe en charge de la publication stable pour savoir si elle accepterait une telle mise à jour puis préparer un envoi vers stable (consultez Cas particulier : distributions stable et oldstable).

3.1.3. Gestion des bogues critiques pour la publication

Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel que cela est décrit en Manipulation des bogues. Cependant, une catégorie spéciale de bogues nécessite particulièrement votre attention : les bogues critiques pour la publication (release-critical ou RC). Tous les rapports de bogue de gravité critical, grave ou serious rendent le paquet inapproprié pour être inclus dans la prochaine version stable. Ils peuvent donc retarder la publication de Debian (quand ils concernent un paquet de testing) ou bloquer des migrations vers testing (quand ils concernent seulement le paquet d'unstable). Au pire, ils pourraient conduire à la suppression du paquet. C'est pourquoi ces bogues doivent être corrigés au plus tôt.

Si pour une raison ou une autre, vous ne pouvez pas corriger un bogue critique pour la publication dans un de vos paquets en moins de deux semaines (par exemple à cause de contraintes de temps, ou parce que c'est compliqué à corriger) vous devriez le signaler clairement dans le rapport de bogue en l'étiquetant help pour encourager d'autres volontaires à s'impliquer. Sachez que les bogues critiques pour la publication sont souvent les cibles de mises à jour indépendantes (consultez Mises à jour indépendantes (NMU)) car ils peuvent bloquer la migration vers testing de plusieurs paquets.

Un manque d'attention aux bogues critiques pour la publication est souvent considéré par l'équipe d'assurance qualité comme un signe de disparition d'un responsable n'ayant pas abandonné correctement son paquet. L'équipe MIA pourrait aussi s'impliquer, avec comme éventuelle conséquence l'abandon de vos paquets (consultez Gestion des responsables non joignables).

3.1.4. Coordination avec les développeurs amont

Une grande part du travail de responsable Debian est de rester en contact avec les développeurs amont. Parfois, les utilisateurs signalent des bogues qui ne sont pas spécifiques à Debian. Ces rapports de bogue doivent être transmis aux développeurs amont pour une correction dans les versions suivantes. Habituellement, c'est ce qu'il y a de mieux à faire si vous le pouvez, sinon, vous pouvez demander à celui qui a soumis le bogue de le faire.

Bien qu'il ne soit pas de votre responsabilité de corriger les bogues non spécifiques à Debian, vous pouvez le faire si vous en êtes capable. Quand vous faites de telles corrections, assurez-vous de les envoyer également au développeur amont. Les utilisateurs et développeurs Debian proposent parfois un correctif pour les bogues amont, il vous faudra alors évaluer ce correctif puis le transmettre aux développeurs amont.

Dans le cas où un rapport de bogue est transmis au développeur amont, n'oubliez pas que le service bts-link peut aider à la synchronisation de l'état des bogues dans le système de suivi de bogues amont et celui de Debian.

Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un paquet conforme à la Charte Debian, vous devriez proposer un correctif aux développeurs amont pour qu'il soit inclus dans leur version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des mises à jour amont suivantes. Quels que soient les changements dont vous avez besoin, il faut toujours essayer de rester dans la lignée des sources amont.

Si vous estimez que les développeurs amont sont ou deviennent hostiles envers Debian ou la communauté du logiciel libre, vous pouvez vouloir reconsidérer le besoin d'inclure le logiciel dans Debian. Parfois, le coût social à la communauté Debian ne vaut pas le bénéfice que le logiciel peut apporter.

3.2. Devoirs administratifs

Un projet de la taille de Debian repose sur certaines structures administratives pour garder une trace de tout. En tant que membre du projet, vous avez quelques devoirs pour veiller à ce que tout se déroule sans problème.

3.2.1. Mise à jour des renseignements auprès de Debian

Une base de données LDAP contient des informations sur les développeurs Debian en https://db.debian.org/. Vous devriez y entrer vos informations et les mettre à jour quand elles changent. Le plus important est de vous assurer que l'adresse vers laquelle est renvoyée le courrier à destination de votre adresse debian.org est toujours à jour, de même que l'adresse à laquelle vous recevez votre abonnement à debian-private si vous choisissez d'être abonné à cette liste.

Pour plus d'informations sur cette base de données, veuillez consulter Base de données des développeurs.

3.2.2. Gestion de clé publique

Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur un serveur public ou sur des machines multi-utilisateurs telles que les serveurs Debian (voir Serveurs Debian). Sauvegardez vos clés et gardez-en une copie hors connexion. Lisez la documentation fournie avec votre logiciel, la FAQ PGP et OpenPGP Best Practices.

Assurez-vous que votre clé est non seulement à l'abri des vols, mais aussi d'une perte. Générez et faites une copie (c'est même mieux sur papier) de votre certificat de révocation ; il est nécessaire si votre clé est perdue ou volée.

Si vous ajoutez des signatures à votre clé publique, ou des identifiants d’utilisateurs, vous pouvez mettre à jour le porte-clés Debian en envoyant votre clé au serveur de clefs à keyring.debian.org.Les mises à jour sont traitées au moins une fois par mois par les responsables du paquet debian-keyring.

Pour ajouter une nouvelle clé ou supprimer une ancienne clé, vous devez faire signer la nouvelle clé par un autre développeur. Si l'ancienne clé est compromise ou non valable, vous devez également ajouter le certificat de révocation. S'il n'y pas de bonne raison pour une nouvelle clé, les responsables du trousseau peuvent rejeter la nouvelle clé. Vous trouverez plus de détails en https://keyring.debian.org/replacing_keys.html.

Les mêmes routines d'extraction de clé décrites en Enregistrement comme responsable Debian s'appliquent.

Une présentation approfondie de la gestion de clé Debian peut être trouvée dans la documentation du paquet debian-keyring et sur le site https://keyring.debian.org/.

3.2.3. Votes

Bien que Debian ne soit pas vraiment une démocratie, le projet utilise un processus démocratique pour élire les responsables de projet et approuver les résolutions générales. Ces procédures sont définies par la constitution Debian.

En dehors de l'élection annuelle du responsable de projet, les votes ne se tiennent pas régulièrement et ne sont pas entrepris à la légère. Chaque proposition est tout d'abord discutée sur la liste de diffusion debian-vote@lists.debian.org et a besoin de plusieurs approbations avant que le secrétaire du projet n'entame la procédure de vote.

You don't have to track the pre-vote discussions, as the secretary will issue several calls for votes on debian-devel-announce@lists.debian.org (and all developers are expected to be subscribed to that list). Democracy doesn't work well if people don't take part in the vote, which is why we encourage all developers to vote. Voting is conducted via OpenPGP-signed/encrypted email messages.

La liste de toutes les propositions (passées et présentes) est disponible sur la page des informations sur les votes Debian, ainsi que des informations complémentaires sur la procédure à suivre pour effectuer une proposition, la soutenir et voter pour elle.

3.2.4. Départ en vacances poli

Il est courant que les développeurs s'absentent, que ce soit pour des vacances prévues ou parce qu'ils sont submergés de travail. L'important est que les autres développeurs ont besoin de savoir si vous êtes indisponible pour pouvoir agir en conséquence si un problème se produit sur vos paquets ou autre pendant votre absence.

Habituellement, cela signifie que les autres développeurs peuvent faire des NMU (voir Mises à jour indépendantes (NMU)) sur votre paquet si un gros problème (bogue empêchant l'intégration dans la distribution, mise à jour de sécurité, etc.) se produit pendant que vous êtes en vacances. Parfois, ce n'est pas très important, mais il est de toute façon approprié d'indiquer aux autres que vous n'êtes pas disponible.

Il y a deux choses à faire pour informer les autres développeurs. Premièrement, envoyez un courrier électronique à debian-private@lists.debian.org en commençant le sujet de votre message par « [VAC] » [1] et donnez la période de vos vacances. Vous pouvez également donner quelques instructions pour indiquer comment agir si un problème survenait.

L'autre chose à faire est de vous signaler comme en vacances (on vacation) dans la Base de données des développeurs (l'accès à cette information est réservé aux développeurs). N'oubliez pas de retirer l'indicateur on vacation à votre retour !

Ideally, you should sign up at the OpenPGP coordination pages when booking a holiday and check if anyone there is looking for signing. This is especially important when people go to exotic places where we don't have any developers yet but where there are people who are interested in applying.

3.2.5. Démission

Si vous décidez de quitter le projet Debian, veillez à procéder comme suit :

• Abandonnez tous vos paquets comme décrit en Abandon de paquet ;

• Retirez-vous des téléverseurs des paquets dont vous êtes co-responsable ou responsable en équipe.

• Si vous recevez des courriels d’alias d’adresse @debian.org (p. ex. press@debian.org) et ne le désirez plus, ouvrez un ticket RT pour les administrateurs du système Debian (Debian System Administrators). Écrivez simplement à admin@rt.debian.org avec « Debian RT » dans le sujet et en déclarant de quel alias vous voulez être supprimé.

• N'oubliez pas de vous retirer des équipes, par exemple des pages wiki des équipes ou des groupes de sala.

• Connectez-vous à nm.debian.org en utilisant le lien https://nm.debian.org/process/emeritus, demandez le statut émérite et écrivez un message d'adieu qui sera envoyé automatiquement à la liste debian-private.

  Authentication to the NM site requires an SSO browser certificate. You can generate them on https://sso.debian.org.

  Au cas où vous rencontrez des difficultés pour initier le processus de démission, contactez le secrétariat des nouveaux membres (NM Front Desk) par un message à nm@debian.org.

Le processus précédemment décrit devrait absolument être suivi, car trouver les développeurs inactifs et déclarer orphelins leurs paquets est une tâche longue et fastidieuse.

3.2.6. Revenir après démission

Le compte d'un développeur est marqué « emeritus » (honoraire) quand le processus précédent en Démission est suivi, et « removed » (supprimé) sinon. Un développeur ayant démissionné avec un compte « emeritus » peut réactiver son compte de la façon suivante :

• Get access to an salsa account (either by remembering the credentials for your old guest account or by requesting a new one as described at SSO Debian wiki page.

• Pour obtenir davantage d'instructions, envoyez un message à nm@debian.org.

• Passer un processus raccourci de nouveau responsable (pour s'assurer qu'il connaît toujours les parties importantes de « philosophie et procédures » et « tâches et compétences »).

Les développeurs ayant démissionné avec un compte « removed » doivent repasser le processus complet de nouveau membre.

[1]

Ainsi, le message peut être facilement filtré par les personnes qui ne veulent pas lire ces annonces de vacances.

4. Ressources pour les membres de Debian

Ce chapitre décrit brièvement les listes de diffusion, les serveurs Debian à disposition des développeurs et les autres ressources utiles au travail de responsable.

4.1. Listes de diffusion

Une grande partie des discussions entre les développeurs Debian (et les utilisateurs) a lieu dans un large éventail de listes de diffusion hébergées sur lists.debian.org. Pour en savoir plus sur la façon de s'abonner ou se désabonner, d'utiliser les listes, de consulter les archives, de contacter leurs responsables, ainsi que diverses autres informations sur les listes de diffusion, veuillez lire https://www.debian.org/MailingLists/. Cette section ne détaille que les informations utiles aux développeurs.

4.1.1. Règles d'utilisation fondamentales

Une réponse sur une liste de diffusion ne doit pas être envoyée en copie (CC) à l'expéditeur initial, sauf s'il l'a explicitement demandé. Toute personne écrivant sur une liste de diffusion devrait la suivre pour voir les réponses.

L'envoi d'un même message à plusieurs listes (« cross-post ») est déconseillé. Conformément aux usages, veuillez réduire la citation des articles auxquels vous répondez. En règle générale, veuillez respecter les conventions habituelles d'envoi de messages.

Veuillez lire le code de conduite pour plus de renseignements. Les recommandations de la communauté Debian (« Debian Community Guidelines ») valent également la peine d'être lues.

4.1.2. Principales listes de diffusion pour les responsables

Les principales listes de diffusion que les développeurs devraient suivre sont :

• debian-devel-announce@lists.debian.org, pour les annonces importantes aux développeurs. Tous les responsables Debian sont censés être inscrits à cette liste ;

• debian-devel@lists.debian.org, pour les diverses questions techniques relatives au développement ;

• debian-policy@lists.debian.org, où la Charte Debian (« Debian Policy ») est discutée et votée ;

• debian-project@lists.debian.org, pour les questions diverses et non techniques relatives au projet.

D'autres listes de diffusion sont spécialisées dans différents thèmes ; voir une liste sur https://lists.debian.org/.

4.1.3. Listes particulières

debian-private@lists.debian.org est une liste de diffusion destinée aux échanges privés entre développeurs Debian. Elle sert aux messages qui, pour une raison ou une autre, ne devraient pas être rendus publics. De ce fait, c'est une liste à faible trafic. Il est déconseillé d'utiliser debian-private@lists.debian.org sauf en cas de réelle nécessité. En outre, il ne faut jamais faire suivre un message provenant de cette liste à qui que ce soit. Les archives de cette liste ne sont pas disponibles sur la toile pour des raisons évidentes, mais il est possible de les consulter dans le répertoire ~debian/archive/debian-private/ sur master.debian.org.

debian-email@lists.debian.org est une liste de diffusion fourre-tout. Elle est utilisée pour les correspondances relatives à Debian qu'il serait utile d'archiver, telles que des échanges avec les auteurs amont à propos de licences, de bogues ou encore des discussions sur le projet avec d'autres personnes.

4.1.4. Demander une nouvelle liste pour le développement

Avant de demander une liste de diffusion pour le développement d'un paquet (ou d'un petit groupe de paquets apparentés), veuillez envisager l'utilisation plus appropriée d'un alias (à l'aide d'un fichier .forward-nom-alias sur master.debian.org, qui se traduit en une adresse plutôt agréable vous-nom-alias@debian.org).

Si une liste de diffusion standard sur lists.debian.org est vraiment ce que vous voulez, lancez-vous et faites une demande en suivant le guide.

4.2. Canaux IRC

Plusieurs canaux IRC sont dédiés au développement de Debian. Ils sont principalement hébergés sur le réseau `Open and Free Technology Community (OFTC)`<https://www.oftc.net/>`__. L'entrée DNS irc.debian.org est un alias vers irc.oftc.net.

Le principal canal pour Debian est #debian. Il s'agit d'un canal important, généraliste, où les utilisateurs peuvent trouver des nouvelles récentes dans le sujet et qui est administré par des robots. #debian est destiné aux anglophones ; il existe également #debian.de, #debian-fr, #debian-br et d'autres canaux avec des noms analogues pour les personnes parlant d'autres langues.

Le canal principal pour le développement de Debian est #debian-devel. C'est un canal très actif puisque plus de 150 personnes sont connectées en permanence. C'est un canal pour les personnes qui travaillent sur Debian, ce n'est pas un canal d'aide (il existe #debian pour cela). Il est cependant ouvert à tous ceux qui veulent écouter (et apprendre). Le sujet est généralement rempli d'informations intéressantes pour les développeurs.

Comme #debian-devel est un canal ouvert, vous ne devriez pas y parler de problèmes discutés sur debian-private@lists.debian.org. Il existe un autre canal dans ce but, appelé #debian-private et protégé par clé. La clé est disponible dans le fichier master.debian.org:~debian/misc/irc-password.

D'autres canaux sont dédiés à des sujets spécifiques. #debian-bugs est utilisé pour la coordination des chasses aux bogues (« bug squashing parties »). #debian-boot est utilisé pour la coordination du travail sur l'installateur Debian (« debian-installer »). #debian-doc est utilisé occasionnellement pour travailler sur la documentation comme celle que vous lisez actuellement. D'autres canaux sont dédiés à une architecture ou un ensemble de paquets : #debian-kde, #debian-dpkg, #debian-perl, #debian-python, etc.

Des canaux existent pour développeurs non anglophones, par exemple, #debian-devel-fr pour les francophones intéressés au développement de Debian.

Channels dedicated to Debian also exist on other IRC networks.

4.3. Documentation

Ce document contient beaucoup d'informations très utiles aux développeurs Debian, mais il ne peut pas tout contenir. La plupart des autres documents intéressants sont référencés dans le coin du développeur Debian. Prenez le temps de parcourir tous les liens, vous apprendrez encore plus de choses.

4.4. Serveurs Debian

Debian possède plusieurs ordinateurs employés comme serveurs, dont la plupart hébergent les fonctions critiques du projet Debian. La plupart des machines sont utilisées pour des activités de portage et elles ont toutes un accès permanent à Internet.

La plupart des machines peuvent être utilisées par les développeurs tant qu'ils respectent les règles définies dans la charte d'utilisation des machines Debian.

Ces machines peuvent être utilisées à votre discrétion pour des buts liés à Debian. Veuillez cependant, par égard aux administrateurs système, ne pas utiliser de grandes quantités d'espace disque, de ressource réseau ou processeur sans obtenir auparavant l'accord des administrateurs. Ces machines sont d'habitude administrées par des bénévoles.

Veuillez prendre soin de vos mots de passe Debian ainsi que des clés SSH installées sur les machines Debian. Évitez les méthodes de connexion ou d'envoi de données qui envoient les mots de passe en clair par Internet comme Telnet, FTP, POP, etc.

Veuillez ne pas déposer de données non relatives à Debian sur les serveurs Debian à moins d'avoir préalablement obtenu la permission de le faire.

La liste à jour des machines Debian est disponible sur la page : https://db.debian.org/machines.cgi. Cette page web contient les noms des machines et permet d'accéder aux informations suivantes : contact, qui peut s'y connecter, clés SSH, etc.

Si vous rencontrez un problème en utilisant un serveur Debian et si vous estimez que les administrateurs système devraient en être avertis, vous pouvez vérifier la liste des tickets ouverts dans la file d'attente relative aux DSA (administrateurs du système Debian « Debian System Administrators ») du gestionnaire de demandes (« request tracker ») sur https://rt.debian.org/ (avec comme identifiant « debian » dont le mot de passe est disponible en master.debian.org:~debian/misc/rt-password). Pour signaler un nouveau problème, il suffit d'envoyer un message à admin@rt.debian.org en s'assurant d'indiquer « Debian RT » dans le sujet. Pour contacter l’équipe DSA par courriel, utilisez dsa@debian.org pour toute chose privée ou confidentielle ne devant pas être publique et debian-admin@lists.debian.org pour tout autre chose. L’équipe DSA est aussi présente sur le canal IRC d’OFTC #debian-admin.

Si le problème est lié à un service particulier, non relatif à l'administration système (paquet à supprimer de l'archive ou suggestion pour le site web par exemple), il faudra en général ouvrir un rapport de bogue sur un « pseudopaquet ». Consultez Signalement de bogues pour connaître la procédure à suivre.

Certains serveurs de base sont à accès restreint, mais les informations de ceux-ci sont fournies par d'autres serveurs miroirs.

4.4.1. Serveur de suivi des bogues (BTS)

bugs.debian.org est le serveur maître du système de suivi des bogues (« Bug Tracking System » ou BTS).

Si vous envisagez de manipuler les bogues ou d'en faire une analyse statistique, ce sera le bon endroit pour le faire. Informez la liste debian-devel@lists.debian.org de votre intention avant d'implémenter quoi que ce soit afin d'éviter un travail en double ou un gaspillage de temps machine.

4.4.2. Serveur FTP principal ftp-master

Le serveur ftp-master.debian.org est le serveur maître de l'archive Debian. En général, les paquets envoyés à ftp.upload.debian.org aboutissent sur ce serveur, voir Envois de paquets.

Ce serveur est à accès restreint ; un miroir est disponible sur mirror.ftp-master.debian.org.

Les problèmes avec l'archive Debian FTP doivent généralement être rapportés comme bogues sur le pseudopaquet ftp.debian.org ou par courrier électronique à ftpmaster@debian.org ; voir Manipulation de paquet dans l'archive pour connaître la procédure à suivre.

4.4.3. Serveur web principal www-master

Le serveur web principal est www-master.debian.org. Il héberge les pages web officielles, la façade de Debian pour la plupart des débutants.

Si vous rencontrez un problème avec un serveur web Debian, vous devriez envoyer un rapport de bogue sur le pseudopaquet www.debian.org. Vérifiez d'abord sur le système de suivi des bogues que le problème n'a pas déjà été signalé.

4.4.4. Serveur web pour pages personnelles people

people.debian.org est le serveur utilisé par les développeurs pour leurs pages concernant Debian.

Si vous avez des informations spécifiques à Debian que vous voulez rendre disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire public_html de votre répertoire personnel sur people.debian.org. Elles seront accessibles à l'adresse https://people.debian.org/~votre-identifiant/.

Vous ne devriez utiliser que cet emplacement particulier, car il sera sauvegardé alors que sur les autres serveurs, ce ne sera pas le cas.

Normalement, la seule raison d'utiliser un serveur différent est pour publier des informations soumises aux restrictions d'exportation américaines. Dans ce cas, vous pouvez utiliser un autre serveur situé en dehors des États-Unis.

Veuillez envoyer toute question à debian-devel@lists.debian.org.

4.4.5. salsa.debian.org : dépôts Git et plateforme de développement collaborative

Si vous souhaitez utiliser un dépôt git pour un de vos projets pour Debian, vous pouvez utiliser à cet effet l'instance de GitLab de Debian nommée Salsa. Gitlab offre aussi la possibilité de faire des requêtes d'intégration, de créer des pages wiki, de bénéficier d'un suivi de bogues entre autres services, aussi bien qu'un réglage fin des droits d'accès, pour faciliter le travail collaboratif sur des projets.

Pour plus d'informations, veuillez consulter la documentation sur la page https://wiki.debian.org/Salsa/Doc.

Any Debian package hosted on Salsa has also access to the Salsa CI . The Salsa CI pipeline mimics the tests that are run after each upload to Debian, but instead of having to wait for results or risk the health of the Debian repositories, Salsa CI provides you with instant feedback about any problems the changes you made may have created or solved.

4.4.6. GitHub.com: Submitting pull requests to upstream repositories

If some upstream repository is hosted on GitHub.com, you can use the Debian organization to create repository forks and submit changed branches with pull requests to upstream maintainers.

The organization is open to all Debian Members. To request membership, open an issue in the Debian/.github meta repository.

4.4.7. Chroots de différentes distributions

Sur certaines machines, des chroots de différentes distributions sont disponibles. Vous pouvez les utiliser comme ceci :

vore$ dchroot unstable
Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable

Dans chaque chroot, les répertoires normaux des utilisateurs sont disponibles. Vous pouvez trouver quels chroots sont disponibles sur https://db.debian.org/machines.cgi.

4.5. Base de données des développeurs

La base de données des développeurs, sur https://db.debian.org/, est un annuaire LDAP regroupant des informations sur les développeurs Debian. Vous pouvez utiliser cette ressource pour rechercher la liste des développeurs Debian. Une partie de ces informations est également disponible avec finger sur les serveurs Debian, essayez finger votreidentifiant@db.debian.org pour voir ce qu'il indique.

Les développeurs peuvent se connecter à la base de données pour modifier différentes informations les concernant, comme :

• l'adresse de réacheminement pour leur adresse debian.org ainsi que la façon de gérer les pourriels. Consultez https://db.debian.org/forward.html pour une description de toutes les options ;

• l'abonnement à debian-private ;

• l'état en vacances ou non ;

• des informations personnelles comme les adresse, pays, latitude et longitude de l'endroit où ils vivent pour utilisation dans la carte mondiale des développeurs Debian, numéros de téléphone et de fax, surnom IRC et page web ;

• le mot de passe et l’interpréteur de commande préféré sur les machines du projet Debian.

La plupart des informations ne sont naturellement pas publiques. Pour plus d'informations, veuillez lire la documentation en ligne sur https://db.debian.org/doc-general.html.

Les développeurs peuvent également envoyer leurs clés SSH afin de les utiliser pour authentification sur les machines Debian officielles et même ajouter de nouvelles entrées DNS du type *.debian.net. Ces fonctionnalités sont documentées sur https://db.debian.org/doc-mail.html.

4.6. Archive Debian

La distribution Debian est composée d'un grand nombre de paquets (environ 30000) et de quelques autres fichiers (comme la documentation et les images de disque d'installation).

Voici un exemple d'arborescence pour une archive Debian complète :

dists/stable/main/
dists/stable/main/binary-amd64/
dists/stable/main/binary-armel/
dists/stable/main/binary-i386/
     ...
dists/stable/main/source/
     ...
dists/stable/main/disks-amd64/
dists/stable/main/disks-armel/
dists/stable/main/disks-i386/
     ...

dists/stable/contrib/
dists/stable/contrib/binary-amd64/
dists/stable/contrib/binary-armel/
dists/stable/contrib/binary-i386/
     ...
dists/stable/contrib/source/

dists/stable/non-free/
dists/stable/non-free/binary-amd64/
dists/stable/non-free/binary-armel/
dists/stable/non-free/binary-i386/
     ...
dists/stable/non-free/source/

dists/stable/non-free-firmware/
dists/stable/non-free-firmware/binary-amd64/
dists/stable/non-free-firmware/binary-armel/
dists/stable/non-free-firmware/binary-i386/
     ...
dists/stable/non-free-firmware/source/

dists/testing/
dists/testing/main/
     ...
dists/testing/contrib/
     ...
dists/testing/non-free/
     ...
dists/testing/non-free-firmware/
     ...

dists/unstable
dists/unstable/main/
     ...
dists/unstable/contrib/
     ...
dists/unstable/non-free/
     ...
dists/unstable/non-free-firmware/
     ...

pool/
pool/main/a/
pool/main/a/apt/
     ...
pool/main/b/
pool/main/b/bash/
     ...
pool/main/liba/
pool/main/liba/libalias-perl/
     ...
pool/main/m/
pool/main/m/mailx/
     ...
pool/non-free/d/
pool/non-free/d/doc-rfc/
     ...
pool/non-free-firmware/f/
pool/non-free-firmware/f/firmware-nonfree/
     ...

Le répertoire racine contient deux répertoires : dists/ et pool/. Le second contient un ensemble de répertoires où sont stockés les paquets, gérés dans la base de données de l'archive, et les programmes d’accompagnement. Le premier répertoire contient les distributions stable, testing et unstable. Les fichiers Packages et Sources des sous-répertoires de distribution font référence aux fichiers du répertoire pool/. Le découpage en sous-répertoires est identique d'une distribution à l'autre. Ce qui est exposé ci-dessous pour la distribution stable est également valable pour les distributions unstable et testing.

dists/stable contains four directories, namely main, contrib, non-free and non-free-firmware.

Dans chacune de ces sections, se trouve un répertoire contenant les paquets source (source/) et un répertoire pour chaque architecture gérée (binary-i386, binary-amd64, etc.).

La section main contient d'autres répertoires destinés aux images de disque et à plusieurs documents essentiels pour installer la distribution Debian sur chaque architecture (disks-i386, disks-amd64, etc.).

4.6.1. Sections

La section main de l'archive constitue la distribution Debian officielle. La section main est officielle parce qu'elle est entièrement conforme à toutes nos recommandations. Les deux autres sections divergent de ces recommandations à différents degrés, elles ne font donc pas officiellement partie de Debian.

Chaque paquet de la section main doit être conforme aux directives Debian pour le logiciel libre (« Debian Free Software Guidelines » ou DFSG) et à toutes les autres recommandations décrites dans la Charte Debian (« Debian Policy Manual »). Les DFSG constituent la définition du « logiciel libre » selon Debian. Reportez-vous à la Charte Debian pour en savoir plus.

Les paquets de la section contrib doivent être conformes aux DFSG, mais ne respectent pas d'autres contraintes. Ils peuvent, par exemple, dépendre de paquets de la section non-free.

Packages which do not conform to the DFSG are placed in the non-free or non-free-firmware sections. These packages are not considered as part of the Debian distribution, though we enable their use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for these non-free software packages.

The Debian Policy Manual contains a more exact definition of the four sections. The above discussion is just an introduction.

The separation of the four sections at the top-level of the archive is important for all people who want to distribute Debian, either via FTP servers on the Internet or on CD-ROMs: by distributing only the main and contrib sections, one can avoid any legal risks. Some packages in the non-free section do not allow commercial distribution, for example.

D'un autre côté, un distributeur de CD-ROM pourra facilement vérifier la licence de chacun des paquets de la section non-free et les intégrer si cela lui est autorisé (dans la mesure où cela varie énormément d'un distributeur à l'autre, ce travail ne peut être fait par les développeurs Debian).

Le terme « section » est également utilisé pour faire référence aux catégories (par exemple admin, net, utils, etc.), ce qui simplifie l'organisation des paquets disponibles et leur recherche. Il fut un temps où ces sections (ou plutôt sous-sections) existaient sous forme de sous-répertoires dans l'archive Debian. Maintenant, elles n'existent plus que dans le champ d’en-tête Section des paquets.

4.6.2. Architectures

À ses débuts, le noyau Linux existait seulement pour les architectures Intel i386 (ou postérieures) ; il en était de même pour Debian. Linux devenant de plus en plus populaire, le noyau a été porté vers d'autres architectures et Debian a commencé à les gérer. Comme si la gestion de nombreuses nouvelles architectures ne suffisait pas, Debian a décidé de construire des portages sur d'autres noyaux de type Unix, comme hurd et kfreebsd.

Debian GNU/Linux 1.3 était disponible uniquement pour i386. Debian 2.0 gérait les architectures i386 et m68k. Debian 2.1 gérait les architectures i386, m68k, alpha et sparc. Depuis, Debian a considérablement évolué. Debian 9 gère un total de dix architectures Linux (amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390 et deux architectures kFreeBSD (kfreebsd-i386 et kfreebsd-amd64).

Pour chaque portage, des informations destinées aux développeurs et utilisateurs sont disponibles sur les pages de portages Debian.

4.6.3. Paquets

Il existe deux types de paquets Debian : les paquets sources et les paquets binaires.

Suivant son format, le paquet source peut être constitué d'un ou plusieurs fichiers en plus du fichier obligatoire .dsc :

• soit un fichier .tar.gz, soit un fichier .orig.tar.gz et un fichier .diff.gz pour le format « 1.0 » ;

• obligatoirement l'archive amont .orig.tar.{gz,bz2,xz}, éventuellement plusieurs archives amont supplémentaires .orig-composant.tar.{gz,bz2,xz} et l'archive debian obligatoire debian.tar.{gz,bz2,xz} pour le format « 3.0 (quilt) » ;

• une seule archive .tar.{gz,bz2,xz} pour le format « 3.0 (native) ».

Si un paquet est développé spécifiquement pour le projet Debian et n'est pas distribué en dehors, il n'y a qu'un fichier .tar.{gz,bz2,xz} qui contient les sources du programme, il est appelé paquet source « natif » (« native »). Si un paquet est distribué ailleurs aussi, le fichier .orig.tar.{gz,bz2,xz} contient ce que l'on appelle le code source amont, c'est-à-dire, le code source distribué par le responsable amont (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier .diff.gz ou debian.tar.{gz,bz2,xz} contient les modifications faites par le responsable Debian.

Le fichier .dsc liste tous les fichiers sources avec leurs sommes de contrôle (md5sums, sha1sums, sha256sums) et quelques informations supplémentaires concernant le paquet (responsable, version, etc.).

4.6.4. Distributions

L'organisation des répertoires présentée précédemment est elle-même contenue dans les répertoires de distributions. Chaque distribution est en fait incluse dans le répertoire pool à la racine de l'archive Debian.

Pour résumer, une archive Debian a un répertoire racine sur un serveur FTP. Par exemple, sur le site miroir ftp.fr.debian.org, l'archive Debian se trouve dans /debian qui est un emplacement courant (un autre emplacement courant est /pub/debian).

Une distribution est composée de paquets source et binaires, et des fichiers Sources et Packages correspondants, qui contiennent toutes les méta-informations sur les paquets. Les premiers sont dans le répertoire pool/ tandis que les seconds sont dans le répertoire dists/ de l'archive (pour rétrocompatibilité).

4.6.4.1. Stable, testing, et unstable

Il existe toujours une distribution appelée stable (dans le répertoire dists/stable), une distribution appelée testing (dans le répertoire dists/testing) et une distribution appelée unstable (dans le répertoire dists/unstable). Cela reflète le processus de développement du projet Debian.

Les développements se font sur la distribution unstable (c'est pourquoi elle est aussi appelée distribution de développement). Chaque développeur Debian peut modifier ses paquets à tout moment dans cette distribution. Ainsi son contenu change tous les jours. Comme aucun effort particulier n'est fait pour s'assurer que tout fonctionne correctement dans cette distribution, elle est parfois littéralement « instable ».

La distribution testing est générée automatiquement en prenant les paquets d'unstable s'ils satisfont à certains critères. Ces critères devraient garantir la bonne qualité des paquets de testing. La mise à jour de testing est effectuée deux fois par jour après l'installation des nouveaux paquets. Voir La distribution testing.

Après une période de développement, quand l'équipe de publication (« release team ») le juge opportun, la distribution testing est gelée, ce qui signifie que les conditions à remplir pour qu'un paquet passe d'unstable à testing sont durcies. Les paquets trop bogués sont supprimés et les seules mises à jours autorisées concernent les corrections de bogues. Après quelque temps, selon l'avancement, la distribution testing est gelée encore plus. Les détails de la gestion de la distribution testing sont publiés par l'équipe de publication sur la liste debian-devel-announce. Une fois les derniers problèmes résolus de façon satisfaisante pour l'équipe de publication, la distribution est publiée. La publication signifie que testing est renommée en stable, une nouvelle copie est créée pour la nouvelle testing, et l'ancienne stable est renommée en oldstable et y reste jusqu'à ce qu'elle soit finalement archivée. Lors de l'archivage, son contenu est déplacé sur archive.debian.org.

Ce cycle de développement est basé sur l'idée que la distribution unstable devient stable après une période de test dans testing. Une distribution contient inévitablement des bogues, même si elle est classée stable. C'est pourquoi la distribution stable est mise à jour de temps en temps. Les corrections introduites sont testées avec une grande attention et sont ajoutées une à une à l'archive pour diminuer les risques d'introduire de nouveaux bogues. Vous pouvez trouver les paquets proposés pour la prochaine mise à jour de stable dans le répertoire proposed-updates. De temps en temps, ces paquets du répertoire proposed-updates qui n'introduisent pas de régression sont installés ensemble dans la distribution stable et le numéro de révision de cette distribution est incrémenté (« 6.0 » devient « 6.0.1 », « 5.0.7 » devient « 5.0.8 » et ainsi de suite). Veuillez vous référer aux Cas particulier : distributions stable et oldstable pour plus de détails.

Note that development in unstable during the freeze should not be continued as usual, as packages are still build in unstable, before they migrate to testing, thus unstable should only contain packages meant for testing. Thus only upload to unstable during freezes, if you are planning to request an unblock (or if the package is not in testing).

Si vous souhaitez développer de nouvelles choses pour après le gel, envoyez les plutôt dans experimental.

4.6.4.2. Informations complémentaires sur la distribution testing

Les paquets sont habituellement installés dans la distribution testing après avoir subi suffisamment de tests dans unstable.

Pour plus de détails, veuillez consulter la section sur La distribution testing.

4.6.4.3. Experimental

La distribution experimental est particulière. Ce n'est pas une distribution à part entière comme le sont stable, testing et unstable. Elle sert de plate-forme de développement pour les projets expérimentaux qui risquent vraiment de détruire le système ou pour des logiciels vraiment trop instables pour être inclus dans la distribution unstable (mais pour lesquels une mise en paquet est justifiée). Les utilisateurs qui téléchargent et installent des paquets d'experimental sont prévenus : on ne peut pas faire confiance à la distribution experimental.

Voici les lignes de sources.list 5 pour experimental :

deb http://deb.debian.org/debian/ experimental main
deb-src http://deb.debian.org/debian/ experimental main

Si un logiciel peut causer des dégâts importants, il sera sûrement préférable de le mettre dans la distribution experimental. Un système de fichiers compressé expérimental, par exemple, devrait probablement aller dans experimental.

Une nouvelle version amont de paquet qui introduit de nouvelles fonctions tout en supprimant de nombreuses autres ne devra pas être ajoutée à l'archive Debian, elle pourra cependant être ajoutée à experimental. Une nouvelle version non finalisée d'un logiciel qui utilise une méthode de configuration complètement différente pourrait aller dans experimental au gré du responsable. Si vous travaillez sur un cas de mise à niveau complexe ou incompatible, vous pouvez aussi utiliser experimental comme plate-forme d'intégration et ainsi fournir un accès aux testeurs.

Quelques logiciels expérimentaux peuvent cependant aller dans unstable, avec un avertissement dans la description, mais ce n'est pas recommandé, car les paquets d'unstable se propagent dans testing et aboutissent dans stable. Vous ne devriez pas avoir peur d'utiliser experimental, car cela ne cause aucun souci aux responsables de l'archive (« ftpmasters »), les paquets expérimentaux sont périodiquement enlevés quand vous envoyez le paquet dans unstable avec un numéro de version supérieur.

Un nouveau logiciel qui ne risque pas d'endommager le système ira directement dans unstable.

Une solution de rechange à experimental consiste à utiliser vos pages personnelles sur le serveur people.debian.org.

4.6.5. Noms de code des distributions

Chaque distribution Debian diffusée a un nom de code : Debian 10 s’appelle buster ; Debian 11, bullseye ; Debian 12, bookworm. La prochaine publication Debian 13, s’appellera trixie et 14 s’appellera forky. Il existe aussi une « pseudodistribution » nommée Sid ; il s'agit de la distribution unstable. Comme les paquets sont déplacés d'unstable vers testing quand ils sont suffisamment stables, la distribution Sid n'est jamais publiée. En plus du contenu habituel d'une distribution Debian, Sid contient des paquets pour des architectures qui ne sont pas encore officiellement prises en charge ou pour lesquelles la distribution n'a pas encore été publiée. Ces architectures seront intégrées ultérieurement à la distribution principale. Les noms de code et les versions des prochaines publications sont listés sur le site web.

Comme Debian est un projet de développement ouvert (où tout le monde peut participer et suivre les développements), même les distributions unstable et testing sont disponibles sur les serveurs HTTP et FTP de Debian. Si nous avions nommé le répertoire qui contient la future distribution « testing », il aurait fallu changer son nom en « stable » au moment de la publication, ce qui aurait forcé les miroirs FTP à télécharger de nouveau la distribution complète (qui est plutôt volumineuse).

D'un autre côté, si une distribution s'appelait Debian-x.y dès le départ, des personnes pourraient s'imaginer que la version x.y de Debian est disponible. (Cela s'est produit par le passé : un distributeur avait gravé un CD-ROM Debian 1.0 en utilisant une version de développement pré-1.0. C'est pour cette raison que la première version officielle était la version 1.1 et non la 1.0.)

En conséquence, les noms de répertoire de distribution dans l'archive sont déterminés par leur nom de code plutôt que par leur état de publication (« bookworm » par exemple). Ces noms sont identiques pendant la période de développement et une fois la distribution diffusée. Des liens symboliques, qui peuvent être modifiés facilement, indiquent la distribution stable actuelle. Tout cela explique pourquoi les répertoires des distributions sont nommés à partir des noms de code des distributions alors que stable, testing et unstable sont des liens symboliques qui pointent vers les répertoires appropriés.

4.7. Miroirs Debian

Les différentes archives de téléchargement et le site web disposent de plusieurs miroirs pour soulager les serveurs principaux d'une charge importante. En fait, certains serveurs principaux ne sont pas publics — la charge est répartie sur une première série de serveurs. De cette façon, les utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et réseaux, et évite aux utilisateurs de surcharger l'emplacement primaire. Dans cette première série, les serveurs sont aussi à jour que possible, car la mise à jour est déclenchée par les sites maîtres internes.

Toutes les informations sur les miroirs Debian peuvent être trouvées sur https://www.debian.org/mirror/, y compris une liste des miroirs publics disponibles par FTP et HTTP. Cette page utile inclut également des informations et des outils pour créer son propre miroir, en interne ou pour un accès public.

Les miroirs sont souvent mis en œuvre par des tiers qui veulent aider Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces machines.

4.8. Système « Incoming »

Le système « Incoming » est responsable de la collecte des paquets mis à jour et de leur installation dans l'archive Debian. Il est constitué d'un ensemble de répertoires et de scripts sur ftp-master.debian.org.

Les paquets sont envoyés par tous les responsables Debian dans un répertoire nommé UploadQueue. Ce répertoire est parcouru toutes les quelques minutes par un démon appelé queued, les fichiers *.command sont exécutés et les fichiers *.changes restants et correctement signés sont déplacés avec leurs fichiers correspondants dans le répertoire unchecked. Ce répertoire n'est pas visible pour la plupart des développeurs, car ftp-master est à accès restreint ; il est parcouru toutes les 15 minutes par le script dak process-upload qui vérifie l'intégrité des paquets envoyés et leurs signatures numériques. Si le paquet est considéré comme prêt à être installé, il est déplacé dans le répertoire done. S'il s'agit du premier envoi du paquet (ou s'il a de nouveaux paquets binaires), il est déplacé dans le répertoire new où il attend l'approbation des responsables de l'archive. Si le paquet contient des fichiers devant être installés manuellement, il est déplacé dans le répertoire byhand où il attend une installation manuelle par les responsables de l'archive. Sinon, quand une erreur a été détectée, le paquet est refusé et déplacé dans le répertoire reject.

Une fois le paquet accepté, le système envoie une confirmation par courrier au responsable et ferme les bogues corrigés. Ensuite, les compilateurs automatiques peuvent commencer leur travail. À ce moment, le paquet est accessible sur https://incoming.debian.org/ avant d'être vraiment installé dans l'archive Debian. Cette opération se produit quatre fois par jour (elle est aussi appelée « dinstall run » pour des raisons historiques) ; le paquet est alors supprimé de incoming et installé dans le pool avec les autres paquets. Une fois toutes les autres mises à jour (fabrication des nouveaux fichiers d'index Packages et Sources par exemple) effectuées, un script spécifique déclenche la mise à jour les miroirs primaires.

The archive maintenance software will also send the OpenPGP signed .changes file that you uploaded to the appropriate mailing lists. If a package is released with the Distribution set to stable, the announcement is sent to debian-changes@lists.debian.org. If a package is released with Distribution set to unstable or experimental, the announcement will be posted to debian-devel-changes@lists.debian.org or debian-experimental-changes@lists.debian.org instead.

Bien que ftp-master soit à accès restreint, une copie de l'installation est disponible à tous les développeurs sur mirror.ftp-master.debian.org.

4.9. Informations sur un paquet

4.9.1. Sur le web

Chaque paquet a plusieurs pages web dédiées. https://packages.debian.org/nom-de-paquet affiche chaque version du paquet disponible dans les différentes distributions. Chaque version fait un lien vers une page qui fournit des informations détaillées comme la description du paquet, les dépendances et des liens pour télécharger le paquet.

Le système de suivi des bogues trie les bogues par paquet. Les bogues de chaque paquet sont disponibles sur https://bugs.debian.org/nom-de-paquet.

4.9.2. Utilitaire dak ls

dak ls fait partie de la suite dak (« Debian Archive Kit ») et liste les versions de paquet disponibles pour toutes les distributions et architectures connues. L'outil dak est disponible sur ftp-master.debian.org et sur le miroir mirror.ftp-master.debian.org. Il utilise un seul paramètre qui correspond au nom du paquet. Un exemple vaut mieux qu'un long discours :

$ dak ls evince
evince     | 3.22.1-3+deb11u2 | oldstable           | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
evince     | 3.22.1-3+deb11u2 | oldstable-debug     | source
evince     | 3.30.2-3+deb12u1 | stable              | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
evince     | 3.30.2-3+deb12u1 | stable-debug        | source
evince     | 3.38.2-1         | testing             | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince     | 3.38.2-1         | unstable            | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince     | 3.38.2-1         | unstable-debug      | source
evince     | 40.4-1           | buildd-experimental | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince     | 40.4-1           | experimental        | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince     | 40.4-1           | experimental-debug  | source

Dans cet exemple, on peut voir que la version dans unstable n'est pas la même que dans testing où seul le binaire a été mis à jour indépendamment (« binary-only NMU ») pour toutes les architectures. Chaque version du paquet a été recompilée sur toutes les architectures.

4.10. Suivi de paquets Debian (Debian Package Tracker)

Le système de suivi de paquets Debian est un outil de suivi, par courrier ou web, de l'activité d'un paquet source. Cela signifie qu’il est possible de recevoir les mêmes courriels que le responsable, simplement en s'inscrivant au paquet dans le suivi de paquets.

Le suivi de paquets possède une interface web sur https://tracker.debian.org/ qui réunit beaucoup d'informations pour chaque paquet source. Plusieurs liens utiles sont proposés (BTS, statistiques QA, informations de contact, état de traduction DDTP, journaux de compilation automatique) et beaucoup d'autres informations provenant de différents endroits sont regroupés (les 30 dernières entrées de changelog, l'état dans testing, etc.). C'est un outil très pratique pour connaître ce qu'il en est d'un paquet source spécifique. De plus, une fois authentifié, il possible de s’inscrire ou désinscrire de n’importe quel paquet d’un simple clic.

Il est possible d'aller directement à la page web concernant un paquet source avec une URL comme https://tracker.debian.org/pkg/paquet-source.

Pour une information plus approfondie, vous devriez regarder dans sa documentation. Entre autres choses, elle explique comment interagir avec lui par courriel, comment filtrer les courriels qu’il transmet, comment configurer vos notifications de commit VCS, comment exploiter ses caractéristiques pour les équipes de responsables, etc.

4.11. Vue d'ensemble des paquets d'un développeur

Un portail web pour l'assurance qualité (« quality assurance » ou QA) sur https://qa.debian.org/developer.php affiche un tableau de tous les paquets d'un développeur (y compris ceux pour lesquels il est co-responsable). Le tableau donne un bon résumé sur les paquets d'un développeur : nombre de bogues par gravité, liste des versions disponibles, état des tests et des liens vers d'autres informations utiles.

C'est une bonne idée de vérifier régulièrement vos données pour ne pas oublier de bogues ouverts et quels paquets sont sous votre responsabilité.

4.12. FusionForge pour Debian : Alioth

Until Alioth was deprecated and eventually turned off in June 2018, it was a Debian service based on a slightly modified version of the FusionForge software (which evolved from SourceForge and GForge). This software offered developers access to easy-to-use tools such as bug trackers, patch managers, project/task managers, file hosting services, mailing lists, VCS repositories, etc.

Il existe des solutions de remplacement pour beaucoup des services offerts précédemment. Il est important de savoir qu'il reste de nombreuses références à alioth à corriger. Si vous rencontrez certaines de ces références, merci de prendre le temps d'essayer de les corriger, par exemple en remplissant des rapports de bogue, ou quand cela est possible, en corrigeant la référence.

4.13. Cadeaux pour les membres de Debian

Les avantages pour les membres de Debian sont documentés sur la page https://wiki.debian.org/MemberBenefits.

5. Gestion des paquets

Ce chapitre contient des informations relatives à la création, l'envoi, la maintenance et le portage des paquets.

5.1. Nouveaux paquets

Si vous voulez créer un nouveau paquet pour la distribution Debian, vous devriez commencer par consulter la liste des paquets en souffrance et paquets souhaités (« Work-Needing and Prospective Packages » ou WNPP). Vous pourrez ainsi vérifier que personne ne travaille déjà sur ce paquet et éviter un travail en double. Consultez aussi cette page si vous voulez en savoir plus.

Supposons que personne ne travaille sur le paquet que vous visez, vous devez alors envoyer un rapport de bogue (voir Signalement de bogues) concernant le pseudopaquet wnpp. Ce courrier devra décrire le paquet que vous projetez de créer, la licence de ce paquet et l'URL à laquelle le code source peut être téléchargé. Cette liste n'est pas limitative.

You should set the subject of the bug to ITP: foo -- short description, substituting the name of the new package for foo. The severity of the bug report must be set to wishlist. Please send a copy to debian-devel@lists.debian.org by using the X-Debbugs-CC header (don't use CC:, because that way the message's subject won't indicate the bug number). If you are packaging so many new packages (>10) that notifying the mailing list in separate messages is too disruptive, send a summary after filing the bugs to the debian-devel list instead. This will inform the other developers about upcoming packages and will allow a review of your description and package name.

Veuillez ajouter « Closes: #nnnnn » au journal de modification (changelog) du nouveau paquet. Cette indication provoquera la fermeture automatique du rapport de bogue à l'installation du nouveau paquet dans l'archive (voir Fermeture des rapports de bogue lors des mises à jour).

Si vous jugez nécessaire d'ajouter des explications pour les administrateurs de la file d'attente de nouveaux paquets (NEW), veuillez les ajouter au fichier changelog, envoyer à ftpmaster@debian.org une réponse au message reçu en tant que responsable suite à votre envoi de paquet, ou une réponse au message de rejet si vous envoyez à nouveau le paquet.

Lors de la fermeture de bogues de sécurité, indiquez les numéros CVE en plus de « Closes: #nnnnn ». Cela permet à l'équipe de sécurité de suivre les failles. Si un envoi est effectué pour corriger le bogue avant que l'identifiant d'alerte soit connu, il est conseillé de modifier la mention existante du fichier changelog lors d'un envoi suivant. Même dans ce cas, veuillez inclure toutes les indications disponibles sur les origines de la situation dans la première entrée de changelog.

Les responsables sont priés d'annoncer leurs intentions pour plusieurs raisons :

• afin d'être informés si quelqu'un travaille déjà sur le paquet et pour permettre à d'autres membres de la liste de partager leur expérience ;

• si d'autres personnes envisagent de travailler sur le même paquet, elles apprendront qu'il existe un volontaire et pourront proposer de partager le travail ;

• cela permet aux autres responsables d'en apprendre plus sur le nouveau paquet que la description courte et la formule consacrée du journal de modification « Initial release » (publication initiale) envoyée sur debian-devel-changes@lists.debian.org ;

• cette information est utile aux utilisateurs d'unstable qui sont les premiers testeurs. Ces personnes devraient être incitées à essayer le nouveau paquet ;

• ces annonces donnent aux responsables et autres personnes intéressées une meilleure idée des évolutions et des nouveautés du projet.

Veuillez consulter https://ftp-master.debian.org/REJECT-FAQ.html pour les raisons courantes de rejet des nouveaux paquets.

5.2. Enregistrement des modifications

Les modifications apportées au paquet doivent être consignées dans le fichier debian/changelog pour être lisibles et compréhensibles par les humains. Ces notes doivent donner une description concise des changements, expliquer les raisons de ceux-ci (si ce n'est pas clair) et indiquer quels rapports de bogue ont été clos. Il faut aussi indiquer quand le paquet a été terminé. Ce fichier sera installé dans /usr/share/doc/paquet/changelog.Debian.gz ou /usr/share/doc/paquet/changelog.gz pour un paquet natif.

Le fichier debian/changelog a une structure précise comportant différents champs. Le champ distribution est décrit en Choix de distribution. Plus d'informations sur la structure de ce fichier sont disponibles dans la section « debian/changelog » de la Charte Debian (« Debian Policy »).

Certaines indications du fichier changelog peuvent provoquer la fermeture automatique des rapports de bogue au moment où le paquet est installé dans l'archive. Voir Fermeture des rapports de bogue lors des mises à jour.

Par convention, quand un paquet contient une nouvelle version amont, le fichier changelog comporte une ligne qui ressemble à :

* New upstream release.

Certains outils peuvent aider à éditer et finaliser le fichier changelog — voir devscripts et dpkg-dev-el.

Voir aussi Meilleures pratiques pour debian/changelog.

5.3. Tests du paquet

Avant d'envoyer un paquet, il faut effectuer quelques tests essentiels. Les opérations suivantes (une ancienne version du paquet est parfois nécessaire) devraient au moins être effectuées :

• Run lintian over the package. You can run lintian as follows: lintian -v package-version.changes. This will check the source package as well as the binary package. If you don't understand the output that lintian generates, try adding the -i switch, which will cause lintian to output a very verbose description of the problem.

  En principe, un paquet pour lequel lintian renvoie des erreurs (elles commencent par E) ne devrait jamais être envoyé.

  Pour en savoir plus sur lintian, voir lintian ;

• facultativement exécuter debdiff (voir debdiff) pour analyser les modifications depuis une ancienne version si celle-ci existe ;

• installer le paquet et s'assurer que le logiciel fonctionne sur un système unstable à jour ;

• mettre à niveau le paquet à partir d'une version plus ancienne vers la nouvelle version ;'

• retirer le paquet et l'installer à nouveau ;

• l'installation, la mise à niveau et le retrait des paquets peuvent être testés manuellement ou en utilisant l'outil piuparts ;

• copier le paquet source dans un répertoire différent puis tenter de le décompresser et de le reconstruire. Le but est de vérifier que la construction n'utilise pas de fichiers en dehors de ceux du paquet ou des permissions non préservées sur les fichiers contenus dans le fichier .diff.gz.

5.4. Agencement du paquet source

Il existe deux types de paquets source Debian :

• les paquets natifs (« native ») pour lesquels il n'y a pas de distinction entre les sources d'origine et les correctifs appliqués pour Debian ;

• les paquets (plus courants) avec au moins une archive, contenant les sources d'origine, accompagnée d'un fichier, contenant les modifications pour Debian.

Pour les paquets natifs, le paquet source comprend un fichier de contrôle source Debian (.dsc) et l'archive source (.tar.{gz,bz2,xz}). Un paquet source d'un paquet non natif comprend un fichier de contrôle source Debian, l'archive source d'origine (.orig.tar.{gz,bz2,xz}) et les modifications Debian (.diff.gz pour le format source « 1.0 » ou .debian.tar.{gz,bz2,xz} pour le format source « 3.0 (quilt) »).

Avec le format « 1.0 », le paquet est soit natif, soit non déterminé par dpkg-source au moment de la construction. Il est dorénavant recommandé de déterminer explicitement le format source en écrivant « 3.0 (quilt) » ou « 3.0 (native) » dans debian/source/format. La suite de cette partie ne traite que les paquets non natifs.

La première fois qu'un paquet est installé dans l'archive pour une version amont donnée, le fichier tar de cette version amont doit être envoyé et mentionné dans le fichier .changes. Par la suite, ce même fichier tar sera utilisé pour générer les fichiers diff et .dsc et il ne sera pas nécessaire de l'envoyer à nouveau.

Par défaut, dpkg-genchanges et dpkg-buildpackage incluront le fichier tar amont si et seulement si la précédente modification de changelog mentionne une version amont différente de la précédente. Ce comportement peut être modifié en utilisant -sa pour l'inclure systématiquement ou -sd pour ne jamais l'inclure.

Si la mise à jour ne contient pas le fichier tar des sources d'origine, dpkg-source doit utiliser le même fichier tar que celui déjà présent dans l'archive pour construire les fichiers .dsc et diff envoyés.

Dans des paquets non natifs, les permissions des fichiers non présents dans l'archive *.orig.tar.{gz,bz2,xz} ne seront pas préservées, car diff ne stocke pas les permissions dans le correctif. Néanmoins, en utilisant le format « 3.0 (quilt) », les permissions des fichiers du répertoire debian seront préservées puisqu'ils seront contenus dans une archive tar.

5.5. Choix de distribution

Chaque envoi doit indiquer à quelle distribution le paquet est destiné. Le processus de construction de paquet extrait cette information à partir de la première ligne du fichier debian/changelog et la place dans le champ Distribution du fichier .changes.

Les paquets sont généralement téléversés dans unstable. Les envois dans unstable ou experimental doivent utiliser ces noms de publication dans le fichier changelog. Les envois pour les autres publications doivent aussi utiliser les noms de code des publications, car ils évitent toute ambiguïté.

En fait, il y a d'autres distributions possibles : nomdecode-security, consultez Gestion des bogues de sécurité pour plus d'informations sur celles-ci.

Il n'est pas possible d'envoyer un paquet dans plusieurs distributions en même temps.

5.5.1. Cas particulier : distributions stable et oldstable

Envoyer un paquet pour la distribution stable signifie que le paquet sera dirigé vers la file d'attente proposed-updates-new pour être revu par les responsables de la publication stable. Une fois accepté, le paquet sera installé dans le répertoire stable-proposed-updates de l'archive Debian. Il sera ensuite ajouté à stable lors de la prochaine mise à jour de la distribution.

Uploads to a supported stable release should target their suite name in the changelog, i.e. bookworm or bullseye. You should normally use reportbug and the release.debian.org pseudo-package to send a source debdiff, rationale and associated bug numbers to the stable release managers, and await a request to upload or further information.

Si vous êtes certain que l'envoi sera accepté sans changement, n'hésitez pas à faire l'envoi en même temps que vous remplissez le bogue sur release.debian.org. Néanmoins, si vous êtes peu familier avec le processus, nous vous recommandons d'attendre l'approbation avant de faire l'envoi pour avoir la possibilité de voir si vos exigences correspondent à celle des responsables de publication.

Dans tous les cas, il faut qu'il y ait un bogue d'accompagnement pour le suivi, et votre envoi doit répondre aux critères d'acceptation définis par les responsables de publication. Ces critères ont été conçus pour faire que le processus rencontre le moins d'obstacles ou de frustration possible.

• Le bogue que vous voulez corriger dans stable doit être déjà corrigé dans unstable (et pas en attente dans NEW ou dans la file d'attente DELAYED).

• Le bogue devrait être de sévérité « important » ou plus haute.

• Les métadonnées du bogue — les versions particulièrement affectées — doivent être à jour.

• Les correctifs doivent être minimaux et pertinents et inclure une entrée de journal de modification suffisamment détaillée.

• Un debdiff source des modifications projetées doit être inclus dans la requête (pas uniquement les correctifs bruts ou la mention « a debdiff can be found at $URL »).

• The proposed package must have a correct version number (e.g. ...+deb12u1 for bookworm or +deb11u1 for bullseye) and you should be able to explain what testing it has had. See the Debian Policy for the version number: https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions

• La mise à jour doit être construite dans un environnement ou un chroot stable (ou oldstable si cette distribution est visée).

• Les corrections de problèmes de sécurité devraient être coordonnées avec l'équipe de sécurité à moins qu'elle n'ait déclaré explicitement qu'elle n'émettrait pas de DSA pour le bogue (par exemple, au moyen d'un indicateur « no-dsa » dans le Gestionnaire de sécurité Debian (« Debian Security Tracker »)).

• Do not close release.debian.org bugs in debian/changelog. They will be closed by the release team once the package has reached the respective point release.

Il est recommandé d'utiliser reportbug, car cela facilite la création de bogues avec des métadonnées correctes. L'équipe de publication fait un usage extensif d'étiquettes pour trier et gérer les requêtes, et les rapports mal étiquetés prennent plus de temps pour être remarqués et traités.

Les mises à jour de la distribution oldstable sont possibles tant qu'elle n'a pas été archivée. Les mêmes règles que pour stable s'appliquent.

Par le passé, les envois vers stable étaient également utilisés pour corriger les problèmes de sécurité. Cependant, cette pratique est déconseillée, car les mises à jour pour les avis de sécurité Debian (« Debian security advisory » ou DSA) sont automatiquement copiées dans l'archive proposed-updates appropriée quand l'avis est publié. Reportez-vous en Gestion des bogues de sécurité pour des informations plus détaillées sur la gestion des problèmes de sécurité. Si l'équipe en charge de la sécurité estime le problème trop insignifiant pour justifier un DSA, les responsables de la publication stable seront cependant plus facilement disposés à intégrer votre correctif par un envoi ordinaire vers stable.

5.5.2. Cas particulier : la publication stable-updates

Parfois les responsables de la publication stable décideront qu'une mise à jour vers stable devrait être mise à disposition des utilisateurs plus tôt que la prochaine mise à jour intermédiaire programmée. Dans ce cas, ils peuvent copier la mise à jour vers la publication stable-updates, dont l'utilisation est activée par défaut par l'installateur.

À l'origine, le processus décrit dans le Cas particulier : distributions stable et oldstable devrait être suivi comme d'habitude. Si vous pensez que l'envoi devrait être publié à travers stable-updates, mentionnez-le dans votre requête. Voici des exemples de circonstances pour lesquelles l'envoi peut être éligible pour ce type de traitement :

• La mise à jour est urgente, mais n'a pas de caractère de sécurité. Les mises à jour de sécurité continueront à être publiées dans l'archive de sécurité. Comme exemple on citera les paquets cassés par le fil du temps (cf. spamassassin et le problème de l'année 2010) et les correctifs des bogues introduits par les versions intermédiaires.

• Le paquet en question est un paquet de données qui doivent être mises à jour dans un délai raisonnable (par exemple, tzdata).

• La correction de paquets en bout de chaîne qui ont été cassés par des modifications externes (par exemple des utilitaires de téléchargement de vidéos et tor).

• Les paquets qui nécessitent d'être à jour pour être utiles (par exemple clamav).

• Uploads to stable-updates should target their suite name in the changelog as usual, e.g. bookworm.

Une fois que l'envoi a été accepté dans proposed-updates et est prêt pour la publication, les responsables de la publication stable le copieront vers la publication stable-updates` et publieront une annonce de mise à jour de stable (Stable Update Announcement ou SUA) sur la liste de diffusion debian-stable-announce.

Toutes les mises à jour publiées par stable-updates seront incluses dans stable avec la prochaine version intermédiaire comme d'habitude.

5.5.3. Cas particulier : testing/testing-proposed-updates

Veuillez consulter les informations des Mises à jour directes dans testing pour plus de détails.

5.6. Envois de paquets

5.6.1. Source and binary uploads

Each upload to Debian consists of a signed .changes file describing the requested change to the archive, plus the source and binary package files that are referenced by the .changes file.

If possible, the version of a package that is uploaded should be a source-only changes file. These are typically named *_source.changes, and reference the source package, but no binary .deb or .udeb packages. All of the corresponding architecture-dependent and architecture-independent binary packages, for all architectures, will be built automatically by the build daemons in a controlled and predictable environment (see wanna-build for more details). However, there are several situations where this is not possible.

The first upload of a new source package (see Nouveaux paquets) must include binary packages, so that they can be reviewed by the archive administrators before they are added to Debian.

If new binary packages are added to an existing source package, then the first upload that lists the new binary packages in debian/control must include binary packages, again so that they can be reviewed by the archive administrators before they are added to Debian. It is preferred for these uploads to be done via the experimental suite.

Uploads that will be held for review in other queues, such as packages being added to the *-backports suites, might also require inclusion of binary packages.

The build daemons will automatically attempt to build any main or contrib package for which the build-dependencies are available. Packages in non-free and non-free-firmware will not be built by the build daemons unless the package has been marked as suitable for auto-building (see Paquets non libres pouvant être automatiquement construits).

The build daemons only install build-dependencies from the main archive area. This means that if a source package has build-dependencies that are in the contrib, non-free or non-free-firmware archive areas, then uploads of that package need to include prebuilt binary packages for every architecture that will be supported. By definition this can only be the case for source packages that are themselves in the contrib, non-free or non-free-firmware archive areas.

Bootstrapping a new architecture, or a new version of a package with circular dependencies (such as a self-hosting compiler), will sometimes also require an upload that includes binary packages.

Binary packages in the main archive area that were not built by Debian's official build daemons will not usually be allowed to migrate from unstable to testing, so an upload that contains binary packages built by the package's maintainer must usually be followed by a source-only upload after the binary upload has been accepted. This restriction does not apply to contrib, non-free or non-free-firmware packages.

5.6.2. Envois sur ftp-master

Pour envoyer un paquet, il faut envoyer les fichiers (y compris les fichiers changes et dsc signés) par FTP anonyme sur ftp.upload.debian.org dans le répertoire /pub/UploadQueue/. Pour que les fichiers y soient traités, ils doivent être signés avec une clé du porte-clés (keyring) des développeurs ou des responsables Debian (voir https://wiki.debian.org/DebianMaintainer).

Attention, il est préférable de transférer le fichier changes en dernier. Dans le cas contraire, votre envoi pourrait être rejeté, car l'outil de maintenance de l'archive pourrait lire le fichier changes et constater que les fichiers ne sont pas tous présents.

Les paquets dupload ou dput pourront vous faciliter le travail lors du téléchargement. Ces programmes bien pratiques aident à automatiser le processus d'envoi de paquets vers Debian.

For removing packages or cancelling an upload, please see ftp://ftp.upload.debian.org/pub/UploadQueue/README and the Debian package dcut.

Enfin, vous devriez réfléchir au statut de votre paquet par rapport à testing avant l'envoi vers unstable. S'il a une version en attente de migration dans unstable, c'est généralement une bonne idée d'attendre sa migration avant d'envoyer une nouvelle version. Vous devriez aussi rechercher dans le Suivi de paquets Debian (Debian Package Tracker) les avertissements detransition pour éviter de procéder à des envois qui perturbent des transitions en cours.

5.6.3. Envois différés

Il peut être utile d'envoyer un paquet à un moment donné, mais vouloir que ce paquet n'entre dans l'archive que quelques jours plus plus tard. Par exemple, lors de la préparation d'une Mises à jour indépendantes (NMU), vous pourriez vouloir donner quelques jours au responsable pour réagir.

Les envois vers le répertoire différé sont gardés dans la file d'attente différée. Une fois le temps d'attente indiqué terminé, le paquet est déplacé dans le répertoire incoming normal pour être traité. Cela est réalisé par une mise à jour automatique en envoyant dans le répertoire DELAYED/X-day (X compris entre 0 et 15) de ftp.upload.debian.org. Le contenu de 0-day est envoyé plusieurs fois par jour vers ftp.upload.debian.org.

With dput, you can use the --delayed DELAY parameter to put the package into one of the queues.

5.6.4. Envois de sécurité

N'envoyez jamais un paquet vers la file d'envoi de sécurité (sur *.security.upload.debian.org) sans avoir auparavant obtenu l'autorisation de l'équipe de sécurité. Si le paquet ne correspond pas tout à fait aux besoins de cette équipe, il entraînera beaucoup de problèmes et de retards dans la gestion de cet envoi non désiré. Pour plus de précisions, consultez Gestion des bogues de sécurité.

5.6.5. Les autres files d'envoi

Une file d'attente alternative en Europe est disponible sur ftp://ftp.eu.upload.debian.org/pub/UploadQueue/. Son fonctionnement est similaire à ftp.upload.debian.org, mais devrait être plus rapide pour les responsables européens.

Les paquets peuvent également être envoyés à l’aide de ssh sur ssh.upload.debian.org ; les fichiers doivent être placés dans /srv/upload.debian.org/UploadQueue. Cette file d'attente ne permet pas les Envois différés.

5.6.6. Notifications

Les administrateurs de l'archive Debian sont responsables de l'installation des mises à jour. La plupart des mises à jour sont gérées quotidiennement par le logiciel de gestion de l'archive dak process-upload. Les mises à jour de paquets sur la distribution unstable sont ainsi installées automatiquement. Dans les autres cas et notamment dans le cas d'un nouveau paquet, celui-ci sera installé manuellement. Il peut s'écouler un peu de temps entre l'envoi d'un paquet vers un serveur et son installation effective. Veuillez être patient.

Dans tous les cas, vous recevrez un accusé de réception par courrier électronique indiquant que votre paquet a été installé et quels rapports de bogue ont été clos. Veuillez lire attentivement ce courrier et vérifier que tous les rapports de bogue que vous vouliez clore sont bien dans cette liste.

L'accusé de réception indique aussi la section dans laquelle le paquet a été installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier qui vous informera de cette différence (voir ci-dessous).

Notez que si vous envoyez en utilisant les files d'attente, le démon vous enverra également une notification par courrier électronique.

Notez aussi que les nouveaux envois sont annoncés sur le Canaux IRC #debian-devel-changes. Si le vôtre échoue sans écho, cela peut être dû à ce que votre paquet n’est pas signé correctement, auquel cas vous pouvez trouver plus d’explications dans ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log.

5.7. Section, sous-section et priorité de paquet

Les champs Section et Priority du fichier debian/control ne précisent pas vraiment l'endroit où le fichier sera placé dans l'archive, ni sa priorité. Afin de conserver l'intégrité globale de l'archive, ce sont les administrateurs de l'archive qui contrôlent ces champs. Les valeurs dans le fichier debian/control sont seulement indicatives.

Les administrateurs de l'archive indiquent les sections et priorités des paquets dans le fichier override. Si ce fichier override et le fichier debian/control du paquet diffèrent, vous en serez informé par courrier électronique quand le paquet sera installé dans l'archive. Vous pouvez corriger votre fichier debian/control avant votre prochain envoi ou alors vous pouvez modifier le fichier override.

Pour modifier la section dans laquelle un paquet est archivé, vous devez d'abord vérifier que le fichier debian/control est correct. Ensuite, envoyez un rapport de bogue sur le pseudopaquet ftp.debian.org demandant la modification de la section ou de la priorité de votre paquet. Utilisez un sujet comme override: PACKAGE1:section/priorité, [...], PACKAGEX: section/priorité, et exposez bien les raisons qui vous amènent à demander ces changements dans le corps de texte.

Pour en savoir plus sur les fichiers override, reportez-vous à dpkg-scanpackages 1 et https://www.debian.org/Bugs/Developer#maintincorrect.

Notez que le champ Section décrit à la fois la section et la sous-section, comme décrit en Sections. Si la section est main, elle devrait être omise. La liste des sous-sections autorisées peut être trouvée en https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections.

5.8. Manipulation des bogues

Chaque développeur doit être capable de travailler avec le système de suivi des bogues de Debian (« ``bubogue correctement (voir Signalement de bogues), comment les mettre à jour, les réordonner, les traiter et les fermer.

Les fonctionnalités du système de suivi des bogues sont décrites dans la documentation du BTS pour les développeurs : fermeture de bogues, envoi de messages de suivi, assignation de niveaux de gravité et de marques, indication que les bogues ont été transmis aux développeurs amonts, etc.

Des opérations comme réassigner des bogues à d'autres paquets, réunir des rapports de bogues séparés traitant du même problème ou rouvrir des bogues quand ils ont été prématurément fermés, sont gérées en utilisant le serveur de contrôle par courrier. Toutes les commandes disponibles pour ce serveur sont décrites dans la documentation du serveur de contrôle du BTS.

5.8.1. Supervision des bogues

Être un bon responsable implique de consulter régulièrement la page du système de suivi des bogues (BTS) de vos paquets. Le système de suivi des bogues contient tous les rapports de bogue qui concernent vos paquets. Vous pouvez les vérifier en consultant cette page : https://bugs.debian.org/votrecompte@debian.org.

Les responsables interagissent avec le système de suivi des bogues en utilisant l'adresse électronique bugs.debian.org. Vous trouverez une documentation sur les commandes disponibles à l'adresse https://www.debian.org/Bugs/ ou, si vous avez installé le paquet doc-debian, dans les fichiers locaux /usr/share/doc/debian/bug-*.

Certains trouvent utile de recevoir régulièrement une synthèse des rapports de bogue ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant tous les rapports de bogue ouverts pour vos paquets, vous pouvez configurer cron comme suit :

# ask for weekly reports of bugs in my packages
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

Remplacez address par votre adresse officielle de responsable Debian.

5.8.2. Réponses aux bogues

Lors d'une réponse à un bogue assurez-vous que toutes les discussions concernant le bogue sont envoyées au rapporteur original du bogue, au bogue lui-même et (si vous n'êtes pas le responsable du paquet) au responsable. L'envoi d'un message à 123@bugs.debian.org enverra le message au responsable du paquet et l'enregistrera dans le journal du bogue. Si vous ne vous souvenez pas de l'adresse courriel du rapporteur, vous pouvez aussi employer 123-submitter@bugs.debian.org pour contacter le rapporteur du bogue. Cette adresse enregistre aussi le message dans le journal du bogue, ainsi, si vous êtes le responsable du paquet en question, il suffit de répondre à 123-submitter@bugs.debian.org. Sinon, vous devrez aussi ajouter l'adresse 123@bugs.debian.org afin d'atteindre également le responsable du paquet.

Si vous recevez un rapport de bogue mentionnant « FTBFS », cela signifie une erreur de construction à partir du paquet source (« Fails To Build From Source »). Les porteurs emploient fréquemment cet acronyme.

Une fois un bogue traité (c'est-à-dire qu'il est corrigé), marquez-le comme done (il sera fermé) en envoyant un message d'explication à 123-done@bugs.debian.org. Si vous corrigez un bogue en changeant et en envoyant une nouvelle version du paquet, vous pouvez fermer le bogue automatiquement comme décrit en Fermeture des rapports de bogue lors des mises à jour.

Vous ne devez jamais fermer un rapport de bogue en envoyant la commande close à l'adresse control@bugs.debian.org. Si vous le faites, le rapporteur n'aura aucune information sur la clôture de son rapport.

5.8.3. Gestion des bogues

En tant que responsable de paquet, vous trouverez fréquemment des bogues dans d'autres paquets et recevrez des rapports de bogue sur vos paquets qui sont en fait relatifs à d'autres paquets. Les fonctions intéressantes du système de suivi des bogues sont décrites dans la documentation du BTS pour les développeurs Debian. Les instructions du serveur de contrôle du BTS documentent les opérations techniques du BTS, telles que comment remplir, réassigner, regrouper et marquer des bogues. Cette section contient des lignes directrices pour gérer vos propres bogues, définies à partir de l'expérience collective des développeurs Debian.

Remplir des rapports de bogue pour des problèmes que vous trouvez dans d'autres paquets est l'une des « obligations civiques » du responsable, voir Signalement de bogues pour les détails. Cependant, gérer les bogues de vos propres paquets est encore plus important.

Voici une liste des étapes que vous pouvez suivre pour traiter un rapport de bogue :

1. décider si le rapport correspond à un bogue réel ou non. Parfois, les utilisateurs utilisent simplement un programme d'une mauvaise façon, car ils n'ont pas lu la documentation. Si c'est votre diagnostic, fermez simplement le bogue avec assez d'informations pour laisser l'utilisateur corriger son problème (donnez des indications vers la bonne documentation et ainsi de suite). Si le rapport de bogue revient régulièrement, vous devriez vous demander si la documentation est assez bonne ou si le programme ne devrait pas détecter une mauvaise utilisation pour donner un message d'erreur informatif. Il s'agit d'un problème qui peut être discuté avec l'auteur amont.

   Si le rapporteur de bogue n'est pas d'accord avec votre décision de fermeture du bogue, il peut le rouvrir jusqu'à ce que vous trouviez un accord sur la façon de le gérer. Si vous n'en trouvez pas, vous pouvez marquer le bogue wontfix pour indiquer à tout le monde que le bogue existe, mais ne sera pas corrigé. Assurez-vous que le rapporteur du bogue comprend les raisons de votre décision en ajoutant une explication au message qui ajoute la marque wontfix.

   Si cette situation n'est pas acceptable, vous (ou le rapporteur) pouvez vouloir demander une décision par le comité technique en ouvrant un nouveau bogue sur le pseudopaquet tech-ctte avec un résumé de la situation. Avant de faire cela, veuillez lire la procédure recommandée ;

2. si le bogue est réel, mais causé par un autre paquet, réassignez simplement le bogue à l'autre paquet. Si vous ne savez pas à quel paquet il doit être réassigné, vous pouvez demander de l'aide sur Canaux IRC ou sur debian-devel@lists.debian.org. Veuillez informer le ou les responsables du paquet sur lequel est réassigné le bogue, par exemple en envoyant une copie du message de réassignation à nomdupaquet@packages.debian.org, en expliquant vos raisons. Attention, une simple réassignation n'envoie pas de courrier aux mainteneurs du paquet auquel le bogue est réassigné, de ce fait ils n'apprendraient l'existence du bogue qu'en regardant la vue d'ensemble des bogues relatifs à leurs paquets.

   Si le bogue affecte le fonctionnement de votre paquet, veuillez envisager de cloner le bogue avant de le réassigner au paquet qui provoque vraiment le comportement. Si vous procédez autrement, le bogue ne sera pas vu dans la liste des bogues sur votre paquet, au risque que d'autres utilisateurs signalent le même bogue de nouveau. Vous devriez marquer « votre » bogue bloqué par le clone réassigné afin de documenter la relation entre les deux bogues ;

3. parfois, vous devez également ajuster la gravité du bogue pour qu'elle corresponde à la définition de gravité des bogues. C'est dû au fait que les gens tendent à augmenter la gravité des bogues pour s'assurer que leurs bogues seront corrigés rapidement. La gravité de certains bogues peut même être rétrogradée en wishlist (souhait) quand le changement demandé est seulement superficiel ;

4. si le bogue est réel, mais que le problème a déjà été rapporté auparavant, alors les deux rapports devraient être rassemblés en un seul à l'aide de la commande merge du BTS. De cette façon, quand un bogue sera corrigé, tous les rapporteurs en seront informés (veuillez notez, néanmoins, qu'un courrier envoyé au rapporteur d'un des bogues ne sera pas automatiquement envoyé aux autres rapporteurs) ;

5. le rapporteur de bogue peut avoir oublié de fournir certaines informations. Dans ce cas, vous devez lui demander les informations nécessaires. Vous pouvez utiliser la marque moreinfo (plus d'information) sur le bogue. De plus, si vous ne pouvez pas reproduire le bogue, vous pouvez le marquer comme unreproducible (non reproductible). Une personne qui arriverait à reproduire le bogue est alors invitée à fournir plus d'informations sur la façon de le reproduire. Après quelques mois, si cette information n'a été envoyée par personne, le bogue peut être fermé ;

6. si le bogue est lié à l'empaquetage, vous devez simplement le corriger. Si vous ne pouvez pas le corriger vous-même, marquez alors le bogue avec help (aide). Vous pouvez également demander de l'aide sur debian-devel@lists.debian.org ou debian-qa@lists.debian.org. S'il s'agit d'un problème amont, vous devez faire suivre le rapport à l'auteur amont. Faire suivre un bogue n'est pas suffisant, vous devez vérifier à chaque version si le bogue a été corrigé ou non. S'il a été corrigé, il vous suffit de le clôturer, sinon vous devez le rappeler à l'auteur. Si vous avez les compétences nécessaires, vous pouvez préparer un correctif pour le bogue et l'envoyer en même temps à l'auteur. Assurez-vous d'envoyer le correctif au BTS et marquez le bogue avec patch (correctif) ;

7. si un bogue a été corrigé sur la copie locale ou sur le système de gestion de versions, il peut être marqué pending (en attente) pour signaler qu'il est corrigé, et sera fermé à la prochaine mise à jour (ajouter « closes: » dans changelog). C'est d'autant plus utile si plusieurs développeurs travaillent sur le même paquet ;

8. une fois le paquet corrigé disponible dans l'archive, le bogue devrait être fermé en précisant dans quelle version du paquet il a été réglé. Cela peut être fait automatiquement, voir Fermeture des rapports de bogue lors des mises à jour.

5.8.4. Fermeture des rapports de bogue lors des mises à jour

Au fur et à mesure que les bogues et problèmes sont corrigés dans vos paquets, il est de votre responsabilité en tant que responsable du paquet de fermer les rapports de bogue associés. Cependant, vous ne devez pas les fermer avant que le paquet n'ait été accepté dans l'archive Debian. C'est pourquoi, vous pouvez et devriez clore les rapports dans le système de suivi des bogues une fois que vous avez reçu l'avis indiquant que votre nouveau paquet a été installé dans l'archive. Le bogue devrait être fermé avec la bonne version.

Cependant, il est possible de fermer automatiquement les bogues après l'envoi — indiquez simplement les bogues corrigés dans le fichier debian/changelog en suivant une syntaxe précise et le logiciel de maintenance de l'archive s'occupera de le fermer pour vous. Par exemple :

acme-cannon (3.1415) unstable; urgency=low

  * Frobbed with options (closes: Bug#98339)
  * Added safety to prevent operator dismemberment, closes: bug#98765,
    bug#98713, #98714.
  * Added man page. Closes: #98725.

D'un point de vue technique, l'expression rationnelle Perl suivante décrit comment sont identifiées les fermetures de bogue dans les lignes de changelog :

/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/ig

La syntaxe « closes: #XXX » est à préférer, car c'est la plus concise et facile à intégrer au texte de changelog. À moins de spécifier un comportement différent avec l'option -v de dpkg-buildpackage, seuls les bogues ainsi marqués dans l'entrée la plus récente de changelog seront fermés (de fait, seuls les bogues signalés dans la partie relative au journal de modification du fichier .changes sont fermés).

Historiquement, les envois identifiés comme Mises à jour indépendantes (NMU) étaient marqués comme fixed au lieu d'être fermés, mais cette pratique a cessé avec l'ajout du suivi des versions. Le même raisonnement s'applique à l'étiquette fixed-in-experimental.

If you happen to mistype a bug number or forget a bug in the changelog entries, don't hesitate to undo any damage the error caused. To reopen wrongly closed bugs, send a reopen XXX command to the bug tracking system's control address, control@bugs.debian.org. To close any remaining bugs that were fixed by your upload, email the .changes file to XXX-done@bugs.debian.org, where XXX is the bug number, and put Version: YYY and an empty line as the first two lines of the body of the email, where YYY is the first version where the bug has been fixed.

Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant le changelog tel que décrit ci-dessus. Si vous désirez simplement fermer les bogues qui n'ont rien à voir avec l'un de vos envois, faites-le simplement en envoyant une explication à XXX-done@bugs.debian.org. Vous ne devez jamais fermer des bogues dans une entrée du journal de modification (changelog) si les changements dans cette version n'ont rien à voir avec le bogue.

Pour une information plus générale sur ce qu'il faut mettre dans les entrées du journal de modification (changelog), voir Meilleures pratiques pour debian/changelog.

5.8.5. Gestion des bogues de sécurité

À cause de leur nature sensible, les bogues liés à la sécurité doivent être soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner cette activité, pour faire le suivi des problèmes de sécurité en cours, pour aider les responsables ayant des problèmes de sécurité ou pour les corriger elle-même, pour envoyer les annonces de sécurité et pour maintenir security.debian.org.

Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un paquet Debian, que vous soyez ou non le responsable, regroupez les informations pertinentes sur le problème et contactez rapidement l'équipe de sécurité par courriel à team@security.debian.org. Si vous le désirez, vous pouvez chiffrer votre courriel avec la clé de contact de l’équipe de sécurité ; consultez https://www.debian.org/security/faq#contact pour plus de détails. N'envoyez pas de paquet pour stable sans contacter l'équipe de sécurité. Les informations utiles comprennent, par exemple :

• si le bogue a déjà été rendu public on non ;

• les versions du paquet affectées par le bogue. Vérifiez chaque version présente dans les distributions maintenues par Debian ainsi que dans testing et unstable ;

• la nature d'une solution si elle existe (les correctifs sont particulièrement utiles) ;

• tout paquet corrigé préparé par vous-même (envoyez seulement le fichier debdiff résultant ou autrement uniquement les fichiers .diff.gz et .dsc et lisez d'abord Préparation de paquets pour les problèmes de sécurité) ;

• toute assistance possible pour aider à tester (exploitation de faille, tests de régression, etc.) ;

• toute information utile pour l'annonce de sécurité (voir Annonces de sécurité).

En tant que responsable d'un paquet, il est de votre devoir de le maintenir, même dans la distribution stable. Vous êtes le mieux placé pour apprécier les correctifs et tester les paquets mis à jour, donc merci de vous référer aux sections suivantes sur la façon de préparer les paquets pour l'équipe en charge de la sécurité.

5.8.5.1. Gestionnaire de sécurité Debian (« Debian Security Tracker »)

L'équipe en charge de la sécurité gère une base de donnée centralisée, le gestionnaire de sécurité Debian (« Debian Security Tracker »). Il contient tous les renseignements publics à propos des problèmes de sécurité connus : quels sont les paquets et versions affectés et non affectés, et par conséquent si stable, testing ou unstable sont vulnérables. Les informations encore confidentielles ne sont pas ajoutées à la base de données.

Il est possible de rechercher un problème particulier, mais aussi un paquet. Cherchez parmi vos paquets afin de prendre connaissance de problèmes non encore résolus. Si vous le pouvez, veuillez fournir plus d'informations sur ces problèmes, ou aidez à les corriger dans vos paquets. Le mode d'emploi est disponible sur les pages web du gestionnaire.

5.8.5.2. Confidentialité

À la différence de la plupart des autres activités de Debian, les problèmes de sécurité doivent parfois être tenus secrets un certain temps. Cela permet aux distributeurs de logiciels de coordonner leur divulgation afin de minimiser l'exposition de leurs utilisateurs. Cette décision dépend de la nature du problème, de l'existence d'une solution correspondante, et de sa publicité.

Il existe plusieurs façons pour un développeur de prendre connaissance d'un problème de sécurité :

• il le remarque sur un forum public (liste de diffusion, site web, etc.) ;

• quelqu'un soumet un rapport de bogue ;

• quelqu'un l'informe en privé.

Dans les deux premiers cas, l'information est publique et il est important de régler le problème au plus vite. Dans le dernier cas, cependant, l'information n'est pas forcément publique. Il existe alors différentes possibilités pour traiter le problème :

• si l'exposition est mineure, il n'y a parfois pas besoin de garder le secret sur le problème et une correction devrait être mise en œuvre et diffusée ;

• si le problème est grave, il vaut mieux partager cette information avec d'autres distributeurs et de coordonner une publication. L'équipe de sécurité est en contact avec les différentes organisations et individus et peut s'en occuper.

Dans tous les cas, si la personne ayant indiqué le problème demande à ce que l'information ne soit pas diffusée, cela devrait être respecté, avec l'évidente exception d'informer l'équipe de sécurité pour préparer un correctif de la version stable de Debian. Quand vous envoyez des informations confidentielles à l'équipe de sécurité, assurez-vous de bien le préciser.

Si le secret est nécessaire, vous ne pourrez pas envoyer de correctif vers unstable (ou ailleurs, comme un système de gestion de version public). Il ne suffit pas d'occulter les détails des modifications : puisque le code lui même est public, il peut être (et sera) étudié.

Il existe deux raisons de diffuser l'information même si le secret est demandé : le problème est connu depuis un certain temps, ou le problème ou son exploitation est devenu public.

L'équipe de sécurité dispose d'une clé PGP pour permettre de chiffrer tout échange d'informations pour les problèmes sensibles. Voir la FAQ de l'équipe Debian sur la sécurité pour plus de détails.

5.8.5.3. Annonces de sécurité

Les annonces de sécurité ne sont émises que pour la distribution actuellement stable, mais pas pour testing ou unstable. Une fois diffusée, l'annonce est envoyée à la liste debian-security-announce@lists.debian.org et mise en ligne sur la page d'informations de sécurité. Les annonces de sécurité sont écrites et mises en ligne par les membres de l'équipe en charge de la sécurité. Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur apporte des informations ou écrive une partie du texte. Les informations d'une annonce devraient comporter :

• une description du problème et de sa portée, y compris :

  • le type du problème (élévation de privilège, déni de service, etc.),

  • quels sont les privilèges obtenus et par quels utilisateurs (si c'est le cas),

  • comment il peut être exploité,

  • si le problème peut être exploité à distance ou localement,

  • comment le problème a été corrigé,

  ces informations permettent aux utilisateurs d'estimer la menace pesant sur leurs systèmes ;

• les numéros de version des paquets affectés ;

• les numéros de version des paquets corrigés ;

• une information sur la façon de récupérer les paquets mis à jour (habituellement l'archive de sécurité Debian) ;

• des références à des annonces amont, des identifiants CVE et toute autre information utile pour recouper les références de la vulnérabilité.

5.8.5.4. Préparation de paquets pour les problèmes de sécurité

Une façon d'aider l'équipe de sécurité dans sa tâche est de lui fournir des paquets corrigés adéquats pour une annonce de sécurité de la version stable de Debian.

Quand une mise à jour de la version stable est effectuée, un soin particulier doit être apporté pour éviter de modifier le comportement du système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de changements possibles pour corriger le bogue. Les utilisateurs et les administrateurs s'attendent à conserver un fonctionnement convenu dans une distribution lorsque celle-ci est publiée, donc toute modification est susceptible de casser le système de quelqu'un. Cela est spécialement vrai pour les bibliothèques : assurez-vous de ne jamais changer l'API (interface de programmation applicative) ou l'ABI (interface binaire-programme), aussi minime que soit le changement.

Cela signifie que passer à une version amont supérieure n'est pas une bonne solution. À la place, les changements pertinents devraient être rétroportés vers la version actuelle de la distribution stable de Debian. Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de sécurité Debian peut le faire.

Dans certains cas, il n'est pas possible de rétroporter un correctif de sécurité, par exemple, quand de grandes quantités de code source doivent être modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à une nouvelle version amont. Cependant, cela n'est fait que dans des situations extrêmes et vous devez toujours coordonner cela avec l'équipe de sécurité auparavant.

Une autre règle importante découle de ce qui précède : testez toujours vos changements. Si une exploitation du problème existe, essayez-la et vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet corrigé. Testez aussi les autres actions normales, car un correctif de sécurité peut parfois casser de manière subtile des fonctionnalités apparemment découplées.

N'ajoutez pas de modifications au paquet qui ne soient pas directement liées à la correction de la vulnérabilité. Celles-ci devraient alors être enlevées, ce qui ne représentera qu'une perte de temps. S'il y a d'autres bogues dans votre paquet que vous aimeriez corriger, faites un envoi vers proposed-updates de la façon habituelle, après l'envoi de l'alerte de sécurité. Le mécanisme de mise à jour de sécurité n'est pas un moyen d'introduire des changements dans votre paquet qui serait sinon rejeté de la distribution stable, veuillez donc ne pas essayer de le faire.

Examinez et testez autant que possible vos changements. Vérifiez les différences avec la version précédente de manière répétée (interdiff du paquet patchutils et debdiff du paquet devscripts sont des outils pratiques pour cela, voir debdiff).

Assurez-vous de garder les points suivants à l'esprit :

• ciblez la bonne distribution dans le fichier debian/changelog : nomdecode-security (par exemple bookworm-security). Ne ciblez ni distribution-proposed-updates, ni stable !

• fournissez des entrées de changelog descriptives et complètes. D'autres personnes se baseront dessus pour déterminer si un bogue particulier a été corrigé. Ajoutez la déclaration closes: pour tout bogue Debian. Intégrez toujours une référence externe, de préférence un identifiant CVE, pour qu'elle puisse être recoupée. Néanmoins, si aucun identifiant CVE n'a encore été assigné, ne l'attendez pas et continuez le processus. L'identifiant pourra être référencé plus tard ;

• assurez-vous que le numéro de version est correct. Il doit être plus élevé que celui du paquet actuel, mais moins que celui des paquets des distributions suivantes. En cas de doute, testez-le avec dpkg --compare-versions. Soyez attentif à ne pas réutiliser un numéro de version déjà utilisé pour un précédent envoi, ou qui entrerait en conflit avec une mise à jour indépendante binaire (binNMU). Par convention, ajoutez +debXu1 (où X est le numéro de publication majeure), par exemple 1:2.4.3-4+deb12u1, bien sûr, incrémentez le nombre final (1 ici) lors des mises à jour suivantes ;

• à moins que l'archive source amont n'ait déjà été envoyée à security.debian.org (lors d'une précédente mise à jour de sécurité), construisez le paquet en incluant l'archive source amont complète (dpkg-buildpackage -sa). Si l'archive source amont a déjà été envoyée à security.debian.org, vous pouvez préparer le paquet en l'excluant (dpkg-buildpackage -sd) ;

• assurez-vous d'utiliser exactement le même ``*.orig.tar.{gz,bz2,xz}`` que celui utilisé dans l'archive normale, sinon il ne sera pas possible de déplacer plus tard le correctif de sécurité dans l'archive principale ;

• compilez le paquet sur un système propre, où tous les paquets appartiennent à la distribution pour laquelle vous construisez le paquet. Si vous ne disposez pas d’un tel système, vous pouvez utiliser l'une des machines de debian.org (voir Serveurs Debian) ou mettre en place un chroot (voir pbuilder et debootstrap).

5.8.5.5. Mise à jour du paquet corrigé

N'envoyez jamais un paquet vers la file d'envoi de sécurité (sur *.security.upload.debian.org) sans avoir auparavant obtenu l'autorisation de l'équipe de sécurité. Si le paquet ne correspond pas tout à fait aux besoins de cette équipe, il entraînera beaucoup de problèmes et de retards dans la gestion de cet envoi non désiré.

Vous ne devez jamais envoyer votre correction dans proposed-updates sans vous coordonner avec l'équipe de sécurité. Les paquets seront copiés de security.debian.org au répertoire proposed-updates automatiquement. Si un paquet avec le même numéro de version ou un numéro plus grand est déjà installé dans l'archive, la mise à jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution stable se retrouvera plutôt sans la mise à jour de sécurité de ce paquet.

Une fois le nouveau paquet créé et testé, et qu'il a été approuvé par l'équipe de sécurité, il doit être envoyé pour être installé dans les archives. Pour les envois de sécurité, l'adresse d'envoi est ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue/.

Une fois l'envoi vers la file d'attente de sécurité accepté, le paquet sera automatiquement recompilé pour toutes les architectures et stocké pour vérification par l'équipe de sécurité.

Les envois en attente d'acceptation ou de vérification ne sont accessibles que par l'équipe de sécurité. C'est obligatoire, car il pourrait y avoir des correctifs pour des problèmes de sécurité qui ne peuvent pas encore être diffusés.

Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur security.debian.org et proposé pour le répertoire distribution-proposed-updates adéquat sur ftp-master.debian.org.

5.9. Manipulation de paquet dans l'archive

Certaines manipulations de l'archive ne sont pas possibles avec le processus de mise à jour automatisé. Elles sont effectuées manuellement par les responsables. Cette partie décrit la marche à suivre dans ces situations.

5.9.1. Déplacement de paquet

Il arrive parfois qu'un paquet change de section. Un paquet de la section non-free pourrait, par exemple, être distribué sous licence GNU GPL dans une nouvelle version ; dans ce cas, le paquet devrait être déplacé vers la section main ou contrib. [1]

Pour changer la section d'un paquet, modifiez les informations de contrôle pour placer le paquet dans la section voulue et envoyez-le à nouveau dans l'archive (voir la Charte Debian pour plus d'informations). Assurez-vous d'inclure le fichier .orig.tar.{gz,bz2,xz} dans l'envoi (même si vous n'envoyez pas de nouvelle version amont) sinon il n'apparaîtra pas dans la nouvelle section avec le reste du paquet. Si la nouvelle section est valable, il sera déplacé automatiquement. Si ce n'est pas le cas, contactez les responsables de l'archive (« ftpmasters ») pour comprendre ce qui s'est passé.

Pour changer la sous-section d'un paquet (devel ou admin par exemple), la procédure est légèrement différente. Modifiez la sous-section dans le fichier de contrôle du paquet et renvoyez-le. Il vous faudra ensuite demander la modification du fichier override comme décrit en Section, sous-section et priorité de paquet.

5.9.2. Suppression de paquet

If for some reason you want to completely remove a package (say, if it is an old compatibility library which is no longer required), you need to file a bug against ftp.debian.org asking that the package be removed; as with all bugs, this bug should normally have normal severity. The bug title should be in the form RM: package [architecture list] -- reason, where package is the package to be removed and reason is a short summary of the reason for the removal request. [architecture list] is optional and only needed if the removal request only applies to some architectures, not all. Note that the reportbug will create a title conforming to these rules when you use it to report a bug against the ftp.debian.org pseudo-package.

Si vous êtes responsable du paquet à supprimer, il faudrait le préciser dans le titre du rapport en commençant celui-ci par la mention ROM (« Request Of Maintainer », demande du responsable). De nombreux autres acronymes sont utilisés pour justifier la suppression d'un paquet, voir la liste complète sur https://ftp-master.debian.org/removals.html. Cette page fournit également une vue d'ensemble des requêtes en cours.

Seuls les paquets d'unstable, experimental ou stable peuvent être supprimés. Les paquets de testing ne sont pas supprimés directement. Ils sont plutôt enlevés automatiquement après suppression d'unstable et si aucun paquet de testing n'en dépend. (Les suppressions de testing sont possibles aussi en soumettant un bogue de suppression sur le pseudopaquet release.debian.org. Consultez la section Suppression de testing.)

Il existe une exception pour laquelle il n'est pas nécessaire de faire une demande explicite de suppression : si un paquet (source ou binaire) ne se construit plus depuis le source, il sera supprimé de façon semi-automatique. Pour un paquet binaire, cela veut dire qu'il n'y a plus de paquet source produisant ce paquet binaire ; si le paquet binaire n'est simplement plus produit pour certaines architectures, une demande de suppression est toujours nécessaire. Pour un paquet source, cela veut dire que tous les paquets binaires auxquels il se réfère ont été récupérés par un autre paquet source.

Il faut détailler dans la demande de suppression les raisons de cette demande. Cela a pour but d'éviter les suppressions indésirables et de garder une trace de la raison pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom du paquet qui remplace celui à supprimer.

Normalement, vous ne devriez demander la suppression d'un paquet que si vous en êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez obtenir l'accord de son responsable. Dans le cas d'un paquet orphelin, qui n'a donc pas de responsable, vous devriez discuter la demande de suppression sur debian-qa@lists.debian.org. S'il existe un consensus sur la suppression du paquet, vous devriez changer le titre et réassigner le bogue O: au paquet wnpp plutôt que d'en ouvrir un autre.

Further information relating to these and other package removal related topics may be found at https://wiki.debian.org/ftpmaster_Removalsand https://qa.debian.org/howto-remove.html.

If in doubt concerning whether a package is disposable, email debian-devel@lists.debian.org asking for opinions. Also of interest is the apt-cache program from the apt package. When invoked as apt-cache showpkg package, the program will show details for package, including reverse depends. Other useful programs include apt-cache rdepends, apt-rdepends, build-rdeps (in the devscripts package) and grep-dctrl. Removal of orphaned packages is discussed on debian-qa@lists.debian.org.

Une fois le paquet supprimé, les bogues du paquet doivent être gérés. Soit ils sont réassignés dans le cas où le code a évolué vers un autre paquet (par exemple, libfoo12 a été supprimé parce que libfoo13 le remplace), soit ils sont fermés si le logiciel ne fait simplement plus partie de Debian. Lors de la fermeture des bogues, pour éviter d'être marqués corrigés dans des versions du paquet disponibles dans des distributions précédentes de Debian, ils devraient être marqués corrigés dans la version <dernière-version-existant-dans-Debian>+rm.

5.9.2.1. Suppression de paquet d'Incoming

Par le passé, il était possible de supprimer un paquet d'incoming. Cependant, ce n'est plus possible depuis la mise en place du nouveau système. [4] À la place, il faut envoyer une nouvelle version du paquet avec un numéro de version plus élevé que celui à remplacer. Les deux versions seront installées dans l'archive, mais seule la plus récente sera réellement disponible dans unstable, car la précédente sera immédiatement remplacée par la nouvelle. Toutefois, si vous testez correctement vos paquets, vous ne devriez pas avoir besoin de les remplacer trop souvent.

5.9.3. Remplacement et changement de nom de paquet

Quand les responsables amont d'un de vos paquet décident de renommer leur logiciel (ou si vous vous trompez en nommant un paquet), vous devrez intervenir en deux étapes pour changer son nom. D'abord, modifiez le fichier debian/control pour que le nouveau paquet remplace (Replaces), fournisse (Provides) et entre en conflit avec (Conflicts) le paquet mal nommé (reportez-vous à la Charte Debian pour les détails). Vous ne devriez ajouter une relation Provides que si tous les paquets dépendants du paquet mal nommé continuent de fonctionner après le changement de nom. Une fois le paquet installé dans l'archive, faites un rapport de bogue concernant le pseudopaquet ftp.debian.org et demandez la suppression du paquet mal nommé (voir Suppression de paquet). N'oubliez pas de réassigner correctement les bogues du paquet en même temps.

Vous pourriez aussi commettre une erreur en construisant le paquet et voulant le remplacer. La seule façon de faire est d'incrémenter le numéro de version et d'envoyer une nouvelle version. L'ancienne version expirera de la façon habituelle. Notez que cela s'applique à chaque partie de votre paquet, y compris les sources : pour remplacer l'archive source amont de votre paquet, envoyez-la avec un numéro de version différent. Une possibilité simple est de remplacer foo_1.00.orig.tar.gz par foo_1.00+0.orig.tar.gz ou foo_1.00.orig.tar.bz2. Cette restriction permet à chaque fichier de l'archive d'avoir un nom unique, ce qui aide à garantir la cohérence dans le réseau des miroirs.

5.9.4. Abandon de paquet

If you can no longer maintain a package, you need to inform others, and see that the package is marked as orphaned. You should set the package maintainer to Debian QA Group <packages@qa.debian.org> and submit a bug report against the pseudo package wnpp. The bug report should be titled O: package -- short description indicating that the package is now orphaned. The severity of the bug should be set to normal; if the package has a priority of standard or higher, it should be set to important. If you feel it's necessary, send a copy to debian-devel@lists.debian.org by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the message's subject won't indicate the bug number).

If you just intend to give the package away, but you can keep maintainership for the moment, then you should instead submit a bug against wnpp and title it RFA: package -- short description. RFA stands for Request For Adoption.

Vous pouvez trouver plus d'informations sur les pages web WNPP (« Work-Needing and Prospective Packages » : paquets en souffrance et paquets souhaités).

5.9.5. Adoption de paquet

Une liste des paquets en attente de nouveau responsable est disponible dans la liste des paquets en souffrance et paquets souhaités (WNPP). Afin de prendre en charge un paquet de cette liste, reportez-vous à la page mentionnée précédemment pour plus d'informations et les procédures à suivre.

Prendre un paquet sans l’accord du responsable actuel n'est pas correct — ce serait un détournement de paquet. Vous pouvez, bien sûr, prendre contact avec le responsable actuel et lui demander si vous pouvez prendre en charge ce paquet.

Cependant, si un paquet est abandonné par son responsable, vous pouvez prendre la responsabilité de ce paquet en suivant le processus de récupération décrit dans Sauvetage de paquets. Si vous avez une raison de croire que le responsable n’est plus du tout actif, consultez Gestion des responsables non joignables.

Les plaintes à propos des responsables devraient être portées sur la liste de diffusion des développeurs. Si la discussion ne se termine pas par une conclusion positive et que le problème est de nature technique, envisagez de porter le cas à l'attention du comité technique (voir la page web du comité technique pour plus d'informations).

Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de suivi des bogues indique que vous êtes le responsable du paquet. Cela se produira automatiquement une fois installé une nouvelle version du paquet dans l'archive avec le champ Maintainer à jour. Cela peut prendre quelques heures après l'envoi. Si vous ne pensez pas faire de mise à jour avant un moment, vous pouvez utiliser le Suivi de paquets Debian (Debian Package Tracker) pour recevoir les rapports de bogue. Cependant, assurez-vous que l'ancien responsable n'est pas embêté de recevoir les rapports de bogue en attendant.

5.9.6. Réintroduction de paquet

Les paquets sont souvent supprimés à cause de bogues critiques pour la publication, de mainteneurs absents, de trop peu d'utilisateurs ou d'une médiocre qualité générale. Alors que le processus de réintroduction de paquet est similaire au processus d'empaquetage initial, certains pièges peuvent être évités en commençant par un peu de recherche historique.

Vous devriez d'abord vérifier la raison pour laquelle le paquet a été supprimé. Ces renseignements sont disponibles dans le paragraphe suppression (« removal ») de la section de nouvelles du PTS pour le paquet ou en consultant le journal des suppressions. Le bogue de suppression indiquera la raison pour laquelle le paquet a été supprimé et donnera quelques indications sur les points à travailler avant de réintroduire le paquet. Cela pourrait indiquer que la meilleure solution est d'utiliser un autre programme au lieu de réintroduire le paquet.

Contacter les précédents responsables peut être utile pour savoir s'ils ont commencé à réintroduire le paquet et s'ils sont intéressés à être coresponsables du paquet ou à parrainer le paquet si nécessaire.

Toutes les étapes nécessaires à l'introduction d'un nouveau paquet (Nouveaux paquets) devraient être suivies.

Le travail devrait être basé sur la dernière version pertinente du paquet disponible. Ce pourrait être la dernière version d'unstable, toujours disponible dans l'archive d'instantanés.

Le système de gestion de versions utilisé par les précédents mainteneurs pourrait contenir des modifications utiles, y jeter un œil pourrait donc être une bonne idée. Vérifiez si le fichier control du précédent paquet contient des en-têtes pointant vers le système de gestion de versions du paquet et s'il existe encore.

Les suppressions de paquet d'unstable (pas de testing, stable ou oldstable) déclenchent la fermeture de tous les bogues relatifs au paquet. Vous devriez passer en revue tous les bogues fermés (y compris les bogues archivés) puis extraire et rouvrir tous ceux qui ont été fermés avec une version se finissant par +rm et toujours d'actualité. Tous ceux qui ne s'appliquent plus devraient être marqués comme corrigés dans la version adéquate si elle est connue.

Les suppressions de paquet d'unstable déclenchent aussi le marquage du paquet comme supprimé dans le Gestionnaire de sécurité Debian (« Debian Security Tracker »).Les membres de Debian devraient marquer les problèmes supprimés comme non corrigés dans le dépôt du suivi de sécurité et tous les autres devraient contacter l'équipe de sécurité pour rapporter les paquets réintroduits.

5.10. Portage

Debian gère un nombre croissant d'architectures. Même si vous n'êtes pas un porteur et que vous utilisez une seule architecture, il est de votre responsabilité de développeur d'être attentif aux questions de portabilité. C'est pourquoi il est important de lire ce chapitre même si vous n'êtes pas un porteur.

Porter un paquet consiste à compiler un paquet binaire pour des architectures différentes de celle du paquet binaire du responsable du paquet. C'est une activité remarquable et essentielle. En fait, les porteurs sont à l'origine de la plupart des compilations de paquets Debian. Par exemple, quand un paquet source (portable) est envoyé avec les paquets binaires i386, il faut compter une compilation pour chaque autre architecture, soit un total de 10 compilations.

5.10.1. Courtoisie avec les porteurs

Les porteurs ont une tâche remarquable et difficile, car ils doivent gérer un grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans modification. Malheureusement, c'est rarement le cas. Cette section contient une liste d'erreurs régulièrement commises par les responsables Debian — problèmes courants qui bloquent souvent les porteurs et compliquent inutilement leur travail.

Ici, le premier et plus important point est de répondre rapidement aux rapports de bogue et problèmes soulevés par les porteurs. Traitez-les courtoisement, comme s'ils étaient coresponsables de vos paquets (ce qu'ils sont d'une certaine manière). Merci pour votre indulgence envers des rapports de bogue succincts ou peu clairs ; faites de votre mieux pour éliminer le problème.

Les problèmes les plus couramment rencontrés par les porteurs sont causés par des erreurs d'empaquetage dans le paquet source. Voici un pense-bête pour les points auxquels vous devez être attentif :

1. vérifiez que les champs Build-Depends et Build-Depends-Indep du fichier debian/control sont corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet debootstrap pour créer un environnement unstable chrooté (voir debootstrap). Dans cet environnement chrooté, installez le paquet build-essential et tous les paquets mentionnés dans les champs Build-Depends ou Build-Depends-Indep. Ensuite, essayez de fabriquer le paquet dans cet environnement. Ces étapes peuvent être automatisées en utilisant le programme pbuilder fourni par le paquet de même nom (voir pbuilder).

   En cas de difficultés pour configurer un environnement chrooté, dpkg-depcheck pourra peut-être vous aider (voir dpkg-depcheck).

   Consultez la Charte Debian pour en savoir plus sur les dépendances de construction ;

2. ne choisissez pas d'autres valeurs que all ou any pour le champ architecture sans avoir de bonnes raisons. Trop souvent, les développeurs ne respectent pas les instructions de la Charte Debian. Choisir la valeur i386 ou amd64 est généralement incorrect ;

3. Make sure your source package is correct. Do dpkg-source -x package.dsc to make sure your source package unpacks properly. Then, in there, try building your package from scratch with dpkg-buildpackage.

4. vérifiez que les fichiers debian/files ou debian/substvars ne sont pas dans votre paquet source. Ils doivent être effacés par la cible clean de debian/rules ;

5. assurez-vous de ne pas dépendre d'éléments de configuration, ou de logiciels installés ou modifiés localement. Par exemple, vous ne devriez jamais appeler des programmes du répertoire /usr/local/bin ou de répertoires équivalents. Essayez de ne pas dépendre de logiciels configurés de manière spéciale. Essayez de construire votre paquet sur une autre machine, même s'il s'agit de la même architecture ;

6. ne vous appuyez pas sur une installation préexistante du paquet (un sous-cas de la remarque précédente). Il existe, bien sûr, des exceptions à cette règle, mais soyez conscient que chaque cas comme celui-ci demande une mise en place (« bootstrapping ») manuelle et ne peut être automatisé par les services d'empaquetage ;

7. si possible, ne dépendez pas d'une version particulière d'un compilateur. Si vous ne pouvez pas faire autrement, assurez-vous que les dépendances de construction reflètent cette restriction, bien que vous cherchiez sûrement les problèmes, puisque certaines architectures s’uniformisent pour différents compilateurs.

8. vérifiez que le fichier debian/rules distingue les cibles binary-arch et binary-indep comme l'exige la Charte Debian. Vérifiez que ces cibles sont indépendantes l'une de l'autre, c'est-à-dire qu'il n'est pas nécessaire d'invoquer l'une de ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez d'exécuter dpkg-buildpackage -B.

9. When you can't support your package on a particular architecture, you shouldn't use the Architecture field to reflect that (it's also a pain to maintain correctly). If the package fails to build from source, you can just let it be and interested people can take a look at the build logs. If the package would actually build, the trick is to add a Build-Depends on unsupported-architecture [!the-not-supported-arch]. The buildds will not build the package as the build dependencies are not fullfiled on that arch. To prevent building on 32-bits architectures, the architecture-is-64bit build dependency can be used, as architecture-is-little-endian can be used to prevent building on big endian systems.

5.10.2. Conseils aux porteurs pour les mises à jour

Si le paquet se construit tel quel sur l'architecture visée, vous avez de la chance et votre travail est facile. Cette section s'applique dans ce cas ; elle décrit comment construire et installer correctement le paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le rendre compilable sur la nouvelle architecture, il faudra faire une NMU sources, consultez plutôt NMU : quand et comment.

Pour un envoi de portage, ne faites pas de changement dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet source, y compris le fichier debian/changelog.

The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B -m porter-email. Of course, set porter-email to your email address. This will do a binary-only build of only the architecture-dependent portions of the package, using the binary-arch target in debian/rules.

Si vous travaillez sur une machine Debian pour vos efforts de portage et que vous devez signer l'envoi localement pour être accepté dans l'archive, vous pouvez exécuter debsign sur le fichier .changes pour qu'il soit signé convenablement, ou utiliser le mode de signature à distance de dpkg-sig.

5.10.2.1. Recompilation ou mise à jour indépendante binaire (binNMU)

Parfois, l'envoi du porteur initial pose problème, car l'environnement dans lequel le paquet a été construit n'était pas bon (bibliothèques périmées ou obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer le numéro de version pour que les mauvais anciens paquets soient remplacés dans l'archive Debian (dak refuse d'installer un nouveau paquet s'il n'a pas un numéro de version supérieur à celui actuellement disponible).

Vous devez vous assurer que votre binNMU ne rend pas le paquet non installable. Cela peut arriver si un paquet source génère des paquets dépendants et indépendants de l'architecture qui ont des interdépendances créées par l’utilisation de la substitution de variable de dpkg $(Source-Version).

Malgré la modification nécessaire du journal de modification (changelog), ce type de mise à jour est appelé binNMU — il n'est pas nécessaire de reconsidérer le statut des paquets binaires des autres architectures pour les marquer périmés ou à recompiler.

Ces recompilations nécessitent des numéros de version « magiques » pour que le système de maintenance de l'archive comprenne que, bien qu'il y ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous ne faites pas cela correctement, les administrateurs de l'archive rejetteront votre mise à jour (car il n'y aura pas de code source associé).

Le « numéro magique » d'une NMU pour une recompilation particulière est obtenu en utilisant un suffixe ajouté au numéro de version du paquet, de la forme bnuméro. Par exemple, si la dernière version recompilée était la version 2.9-3, la binNMU aura pour version 2.9-3+b1. Si la dernière version était 3.4+b1 (c'est-à-dire un paquet natif avec une précédente NMU par recompilation), la binNMU aura le numéro de version 3.4+b2. [2]

De manière similaire aux envois du porteur initial, la façon correcte d'invoquer dpkg-buildpackage est dpkg-buildpackage -B pour ne construire que les parties dépendant de l'architecture du paquet.

5.10.2.2. Quand utiliser une NMU source pour un portage

Les porteurs faisant des NMU source suivent normalement les instructions de Mises à jour indépendantes (NMU), tout comme les non-porteurs. Les délais d'attente sont cependant réduits, car les porteurs doivent manipuler un grand nombre de paquets. À nouveau, la situation diffère selon la distribution visée. Elle varie également si l'architecture est candidate pour la prochaine version stable ; les responsables de publication décident et annoncent quelles sont les architectures candidates.

Si vous êtes porteur et faites une NMU pour unstable, les instructions précédentes sont applicables à deux différences près. Tout d'abord, le temps d'attente raisonnable — délai entre le moment où vous envoyez un rapport au BTS et le moment où vous pouvez faire une NMU — est de sept jours. Ce délai peut être réduit si le problème est crucial et met l'effort de portage en difficulté : c'est à la discrétion de l'équipe de portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de recommandations communément acceptées). Pour les envois de stable ou testing, veuillez d'abord vous coordonner avec l'équipe de publication concernée.

Deuxième différence, les porteurs faisant des NMU source doivent choisir une gravité serious (sérieuse) ou supérieure quand ils envoient leur rapport au BTS. Cela assure qu'un paquet source unique permet de produire un paquet binaire pour chaque architecture maintenue au moment de la sortie de la distribution. Il est très important d'avoir un paquet source et un paquet binaire pour toutes les architectures pour être conforme à plusieurs licences.

Les porteurs doivent éviter les correctifs qui contournent les bogues des actuelles versions de l'environnement de compilation, du noyau ou de la libc. Parfois, ces contournements ne peuvent être améliorés. Si vous devez faire quelque chose de ce genre, marquez proprement vos modifications avec des #ifdef et documentez votre contournement pour pouvoir le retirer une fois le problème externe disparu.

Les porteurs peuvent aussi avoir un dépôt non officiel pour publier le résultat de leur travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces dépôts n'ont rien d'officiel, donc soyez sur vos gardes si vous les utilisez.

5.10.3. Infrastructure de portage et automatisation

Une infrastructure et plusieurs outils sont disponibles pour faciliter l'automatisation du portage des paquets. Cette section contient un bref aperçu de cette automatisation et de ces outils ; veuillez vous reporter à la documentation des paquets ou les références pour des informations complètes.

5.10.3.1. Listes de diffusion et pages web

Les pages web contenant l'état de chaque portage peuvent être trouvées à https://www.debian.org/ports/.

Chaque portage de Debian possède sa propre liste de diffusion. La liste des listes de diffusion de portage peut être trouvée à https://lists.debian.org/ports.html. Ces listes sont utilisées pour coordonner les porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les porteurs.

5.10.3.2. Outils pour les porteurs

Les descriptions de plusieurs outils de portage peuvent être trouvées en Outils de portage.

5.10.3.3. wanna-build

Le système wanna-build est un système distribué pour la compilation d'une distribution. Il est habituellement utilisé en conjonction avec des automates de compilation faisant fonctionner le programme buildd. Les automates de compilation (« build daemons ») sont des machines « esclaves » qui récupèrent la liste des paquets à compiler du système principal wanna-build.

wanna-build n'est pas encore disponible sous forme de paquet ; pourtant, tous les efforts de portage l'utilisent pour automatiser la compilation de paquets. L'outil de compilation vraiment utilisé est dans le paquet sbuild, voir la description en sbuild. La version empaquetée n'est pas la même que celle utilisée sur les automates de compilation, mais suffisamment proche pour reproduire les problèmes.

La plupart des informations produites par wanna-build, souvent utiles pour les porteurs, sont disponibles sur la toile à l'adresse https://buildd.debian.org/. Les données disponibles sont entre autres les statistiques mises à jour chaque nuit, les informations de file d'attente et les journaux de tentatives de compilation.

Ce système est une fierté de Debian, car il a de nombreux usages potentiels. Il peut être utilisé par des groupes de développeurs indépendants pour créer différentes variantes de Debian d'intérêt général ou non (par exemple, une variante de Debian compilée avec des vérifications de limites (« bounds checking ») de gcc). Ce système permettra aussi de recompiler rapidement toute une distribution.

L'équipe de wanna-build, en charge des empaqueteurs (« buildd »), peut être contactée à l'adresse électronique debian-wb-team@lists.debian.org. Pour savoir qui (équipe de wanna-build, équipe de publication) et comment (courrier électronique, BTS) contacter, se reporter à https://lists.debian.org/debian-project/2009/03/msg00096.html.

Lors d'une demande de mise à jour indépendante binaire (binNMU) ou de « rendu » (« give-back » : nouvel essai suite à une compilation échouée), veuillez utiliser le format décrit en https://release.debian.org/wanna-build.txt.

5.10.4. Paquet non portable

Certains paquets ont encore des problèmes pour être construits ou pour fonctionner sur certaines architectures prises en charge par Debian, et ne peuvent pas du tout être portés, ou pas dans un délai raisonnable. Par exemple, un paquet spécifique à SVGA (disponible uniquement sur i386 et amd64), ou qui utilise des fonctionnalités spécifiques au matériel non gérées sur toutes les architectures.

Pour éviter que des paquets cassés soient envoyés dans l'archive et qu'ils fassent perdre le temps des empaqueteurs (« buildd »), vous devez faire plusieurs choses :

• tout d'abord, assurez-vous que votre paquet échoue à la compilation sur les architectures qu'il ne gère pas. Il y a plusieurs façons de faire cela. Le meilleur moyen est d'avoir une petite suite de tests pendant la construction qui vérifiera la fonctionnalité et échouera si cela ne fonctionne pas. C'est de toute façon une bonne idée et empêchera (certains) des envois cassés pour toutes les architectures, cela permettra également au paquet d'être construit dès que la fonctionnalité nécessaire sera disponible.

  De plus, si vous croyez que la liste des architectures gérées est plutôt constante, vous devriez changer any en une liste des architectures gérées dans le fichier debian/control. Ainsi, la construction échouera également et l'indiquera à un lecteur humain sans vraiment essayer ;

• pour empêcher les compilateurs automatiques de tenter sans raison de construire votre paquet, il doit être inclus dans Packages-arch-specific, une liste utilisée par le script wanna-build. La version actuelle est disponible en https://wiki.debian.org/PackagesArchSpecific ; veuillez consulter le début du fichier pour savoir qui contacter pour le modifier.

Il ne suffit pas d'ajouter votre paquet à Packages-arch-specific sans le faire échouer lors de compilation sur les architectures non gérées : un porteur ou toute autre personne essayant de construire votre paquet peut accidentellement l'envoyer sans remarquer qu'il ne fonctionne pas. Si par le passé, certains paquets binaires ont été envoyés pour des architectures non gérées, demandez leur suppression en remplissant un bogue sur ftp.debian.org.

5.10.5. Paquets non libres pouvant être automatiquement construits

By default packages from the non-free and non-free-firmware sections are not built by the autobuilder network (mostly because the license of the packages could disapprove). To enable a package to be built, you need to perform the following steps:

1. vérifier s'il est légalement permis et techniquement possible de construire automatiquement le paquet ;

2. ajouter XS-Autobuild: yes dans la partie en-tête de debian/control ;

3. envoyer un courrier à non-free@buildd.debian.org et expliquer pourquoi le paquet peut légalement et automatiquement être construit.

5.11. Mises à jour indépendantes (NMU)

Chaque paquet est géré par un ou plusieurs responsables. Normalement, ce sont eux qui travaillent sur les paquets et s'occupent de les mettre à jour. Dans certains cas, il est utile que d'autres développeurs puissent aussi envoyer une nouvelle version, par exemple pour résoudre un bogue dans un paquet dont ils ne sont pas responsables, lorsque le responsable a besoin d'aide pour réagir aux problèmes. De tels envois sont appelés mises à jour indépendantes (« ``Non-Maintainer Uploads`` » ou ``NMU``).

5.11.1. NMU : quand et comment

Avant de procéder à une NMU, veuillez prendre en considération les questions suivantes.

• Avez-vous adapté le NMU de façon à aider le responsable ? Puisqu’il pourrait exister un désaccord sur le fait que le responsable ait vraiment besoin d’aide ou pas, la file d’attente DELAYED est là pour donner au responsable le temps de réagir et permet, comme effet de bord, de permettre des révisions indépendantes du diff de la NMU.

• Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g. wishlist bugs for packaging a new upstream version, but care should be taken to minimize the impact to the maintainer.) Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.

• Avez-vous laissé suffisamment de temps au responsable ? Quand le bogue a-t-il été reporté au BTS ? Être occupé pendant une semaine ou deux n'est pas exceptionnel. Le bogue est-il si grave qu'il doive être corrigé immédiatement, ou cela peut-il attendre encore quelques jours ?

• Quelle confiance avez-vous dans vos modifications ? Souvenez-vous du serment d'Hippocrate : « je m'abstiendrai de tout mal ». Il est préférable de laisser un paquet avec un bogue ouvert grave plutôt qu'appliquer un correctif non fonctionnel ou un correctif qui cache le bogue sans le résoudre. Si vous n'êtes pas absolument sûr de vous, il pourrait être judicieux de chercher des conseils autour de vous. Rappelez-vous que si quelque chose est cassé par votre NMU, de nombreuses personnes seront mécontentes.

• Avez-vous clairement manifesté votre intention de procéder à une NMU, au moins dans le BTS ? En l’absence de réaction, une bonne idée serait d'essayer de contacter le responsable par d'autres moyens (courriel aux responsables ou personnel, IRC).

• Si le responsable est habituellement actif et réactif, avez-vous tenté de le contacter ? En général il est préférable que le responsable prenne en charge lui-même un problème et qu'il lui soit offert une chance d'examiner et corriger votre correctif, car il est censé être mieux placé pour découvrir d'éventuels problèmes que vous pourriez rater. C'est souvent un gain de temps pour tout le monde si le responsable a la possibilité d'envoyer lui-même une correction.

Lors d'une NMU, vous devez d'abord vous assurer que votre intention est sans ambiguïté. Ensuite, vous devez envoyer un correctif contenant les différences entre le paquet actuel et votre proposition de NMU au BTS. Le script nmudiff du paquet devscripts pourrait être utile.

While preparing the patch, you had better be aware of any package-specific practices that the maintainer might be using. Taking them into account reduces the burden of integrating your changes into the normal package workflow and thus increases the chances that integration will happen. A good place to look for possible package-specific practices is debian/README.source.

À moins d'avoir une excellente raison de ne pas le faire, vous devez laisser du temps au responsable pour réagir (par exemple en envoyant le paquet dans la file DELAYED). Voici quelques valeurs recommandées pour les délais :

• envoi corrigeant seulement un bogue critique pour la publication ouvert il y a plus de sept jours, sans action du responsable sur le bogue pendant sept jours, et sans indication qu'un correctif est en cours : zéro jour ;

• envoi corrigeant seulement un bogue critique pour la publication ouvert il y a plus de sept jours : deux jours ;

• envoi corrigeant seulement un bogue critique pour la publication et important : cinq jours ;

• autres NMU : dix jours.

Ces délais sont simplement donnés à titre indicatifs. Dans certains cas, comme des envois corrigeant des problèmes de sécurité, ou corrigeant des bogues insignifiants qui bloquent une transition, il est préférable que le paquet atteigne unstable au plus tôt.

Parfois, les responsables de publication peuvent décider d'encourager des délais plus courts pour les NMU corrigeant un sous-ensemble de bogues (par exemple les bogues critiques pour la publication ouverts il y a plus de sept jours). Certains responsables s'inscrivent d'eux-mêmes à la liste permissive de NMU (« ``Low Threshold NMU list` ») <https://wiki.debian.org/LowThresholdNmu>`__, et acceptent que les NMU soient effectuées sans délai. Mais même dans ce cas, il est toujours préférable de laisser quelques jours au responsable pour réagir avant votre envoi, d'autant plus si le correctif n'était pas disponible auparavant dans le BTS, ou si vous savez que le responsable est habituellement actif.

Après une NMU, vous êtes responsable d'éventuels problèmes introduits. Vous devez garder un œil sur le paquet (s'abonner au paquet dans le PTS est un bon moyen).

Il ne s'agit pas d'un permis pour faire des NMU irréfléchies. Si vous procédez à une NMU alors que le responsable est clairement actif et aurait pris en considération un correctif de façon opportune, ou si vous passez outre les recommandations de ce document, votre envoi risque d'être une cause de conflit avec le responsable. Vous devriez toujours être prêt à défendre le bien-fondé de toute NMU effectuée.

5.11.2. NMU et debian/changelog

Comme tout autre envoi (de paquet source), les NMU doivent comporter une nouvelle entrée dans le fichier debian/changelog, expliquant les modifications effectuées dans cet envoi. La première ligne de cette entrée doit signaler explicitement qu'il s'agit d'une NMU, par exemple :

* Non-maintainer upload.

La façon de numéroter les versions lors d'une NMU est différente s'il s'agit d'un paquet natif ou non.

Si le paquet est natif (sans partie révision Debian dans le numéro de version du paquet), la version doit être celle du dernier envoi du responsable, suivi de +nmuX, où X est un compteur commençant à 1. Si le dernier envoi était également une NMU, le compteur devrait être augmenté. Par exemple, si la version actuelle est 1.5, alors une NMU devrait prendre la version 1.5+nmu1.

Si le paquet n'est pas natif, vous devriez ajouter un numéro de version mineure à la partie révision Debian du numéro de version (la partie après le dernier tiret). Ce numéro supplémentaire devrait commencer à 1. Par exemple si la version actuelle est 1.5-2, alors une NMU devrait prendre la version 1.5-2.1. Si une nouvelle version amont est empaquetée lors de la NMU, la révision Debian est configurée à 0, par exemple 1.6-0.1.

Dans les deux cas, si le dernier envoi était également une NMU, le compteur devrait être augmenté. Par exemple, si la version actuelle est 1.5+nmu3 (un paquet natif déjà mis à jour indépendamment), la NMU devrait prendre la version 1.5+nmu4.

Une numérotation de version spécifique est nécessaire pour éviter de perturber le travail du responsable, car l'utilisation d'un entier dans la révision Debian risque d'entrer en conflit avec un envoi déjà en préparation lors de la NMU, ou même déjà dans la file d'attente de nouveaux paquets (NEW), Cela présente également l'avantage d'indiquer clairement que le paquet dans l'archive n'a pas été préparé par le responsable officiel.

Lors d'un envoi de paquet vers testing ou stable, il est parfois nécessaire de créer une branche (« fork ») dans l'arbre de numérotation des versions. C'est par exemple le cas pour les mises à jour de sécurité. Pour cela, une version de la forme +debXuY devrait être utilisée, X étant le numéro de publication majeure et Y étant un compteur qui commence à 1. Par exemple, alors que bookworm (Debian 12) est stable, une NMU de sécurité pour un paquet dont la version est 1.5-3 devrait avoir la version 1.5-3+deb12u1, alors qu'une NMU de sécurité vers trixie devrait prendre la version 1.5-3+deb13u1.

5.11.3. Utilisation de la file d'attente DELAYED/

Attendre une réponse après avoir demandé la permission de procéder à une NMU est inefficace, car cela coûte au demandeur un changement de contexte (« context switch ») pour revenir sur le problème. La file d'attente DELAYED/ (voir Envois différés) permet au développeur préparant une NMU d'accomplir toutes les tâches nécessaire en même temps. Par exemple, plutôt que dire au responsable que vous allez envoyer le nouveau paquet dans sept jours, vous devriez envoyer le paquet vers DELAYED/7 et dire au responsable qu'il a sept jours pour réagir. Pendant ce temps, le responsable peut vous demander de retarder un peu plus votre envoi, ou l'annuler.

You can cancel your upload using dcut. In case you uploaded foo_1.2-1.1_all.changes to a DELAYED queue, you can run dcut cancel foo_1.2-1.1_all.changes to cancel your upload. The .changes file does not need to be present locally as you instruct dcut to upload a command file removing a remote filename. The .changes file name is the same that you used when uploading.

La file d'attente DELAYED ne devrait pas être utilisée pour augmenter la pression sur le responsable. Notamment, il est important d'être disponible pour annuler ou retarder l'envoi avant la fin du délai, car le responsable ne peut pas le faire lui-même.

Si vous procédez à une NMU vers DELAYED et que le responsable envoie son paquet avant la fin du délai, votre envoi sera rejeté, car une nouvelle version sera alors disponible dans l'archive. Dans l'idéal, le responsable se chargera d'intégrer votre proposition (ou du moins une solution pour le problème en question) dans son envoi.

5.11.4. NMU d'un point de vue du responsable

Quand quelqu'un réalise une NMU sur votre paquet, c'est pour vous aider à le garder en bon état. Cela permet aux utilisateurs d'obtenir un paquet corrigé au plus vite. Vous pouvez envisager de proposer à l'auteur de la NMU de devenir coresponsable du paquet. Recevoir une NMU sur un paquet n'est pas une mauvaise chose : cela signifie simplement que le paquet est suffisamment intéressant pour que d'autres personnes veuillent travailler dessus.

Pour prendre en compte une NMU, intégrez ses modifications et l'entrée de journal de modification (changelog) lors de votre envoi suivant. Si vous ne prenez pas en compte la NMU en conservant l'entrée de changelog correspondante, le bogue restera fermé dans le BTS, mais sera listé comme affectant votre version du paquet.

Notez que si vous avez besoin d’annuler une NMU qui a empaqueté une nouvelle version amont, il est recommandé d’utiliser une version amont factice telle que ACTUEL+reallyANCIEN jusqu’à ce que quelqu’un puisse téléverser à nouveau la dernière version. Plus d’informations sont disponibles dans https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly.

5.11.5. Mise à jour indépendante source (NMU) vs binaire (binNMU)

Le nom complet pour une NMU est mise à jour indépendante source (« ``source NMU`` »). Il en existe aussi d'un autre type, appelé mise à jour indépendante binaire (« ``binary-only NMU`` » ou « ``binNMU`` »). Une binNMU est aussi un paquet envoyé par quelqu'un d'autre que le responsable du paquet. Cependant, seul le paquet binaire est mis à jour.

Lorsqu'une bibliothèque (ou toute autre dépendance) est mise à jour, les paquets l'utilisant risquent de devoir être reconstruits. Puisque le code source n'a pas besoin d'être modifié, le même paquet source est utilisé.

Les binNMU sont généralement déclenchées sur les empaqueteurs (« buildd ») par wanna-build. Une entrée est ajoutée à debian/changelog expliquant pourquoi un envoi était requis et le numéro de version est augmenté tel que décrit en Recompilation ou mise à jour indépendante binaire (binNMU). Cette entrée ne devrait pas être gardée lors de l'envoi suivant.

Les empaqueteurs (« buildd ») envoient les paquets de leur architecture comme des mises à jour binaires. Au sens strict, ce sont des binNMU. Cependant, elles ne sont généralement pas appelées NMU, et aucune entrée n'est ajoutée à debian/changelog.

5.11.6. NMU et envoi de QA

Les NMU sont des envois effectués par quelqu'un d'autre que le responsable attitré. Il existe un autre type d'envoi où le paquet mis à jour ne vous appartient pas : les envois de QA, qui sont des envois pour les paquets orphelins.

Les envois de QA ressemblent beaucoup à des envois normaux de responsable : ils peuvent corriger quelque chose, même un problème mineur ; la numérotation de version est normale, et il n'est pas nécessaire d'utiliser d'envoi retardé. La différence est que vous ne faites pas partie des responsables (Maintainer ou Uploader) du paquet. Ainsi, l'entrée du journal de modification (changelog) d'un envoi de QA commence par la ligne :

* QA upload.

Si vous voulez faire une NMU, et que le responsable ne semble pas actif, il est judicieux de vérifier le paquet pour voir s'il est orphelin (cette information est disponible sur la page du système de suivi relative au paquet). Lors d'un premier envoi de QA sur un paquet orphelin, veuillez positionner le responsable à « Debian QA Group <packages@qa.debian.org> ». La liste actuelle des paquets orphelins dont le responsable n'a pas encore été modifié est disponible en https://qa.debian.org/orphaned.html.

Plutôt que faire un envoi de QA, vous pouvez envisager l'adoption du paquet en devenant son responsable. Vous n'avez besoin de la permission de personne pour adopter un paquet orphelin, il suffit de vous configurer comme responsable et d'envoyer la nouvelle version (voir Adoption de paquet).

5.11.7. NMU et envoi d'équipe

Parfois, vous corrigez ou envoyez un paquet, car vous êtes membre d'une équipe de responsables (qui utilise une liste de diffusion comme responsable (Maintainer ou Uploader), voir Maintenance collective), mais vous ne voulez pas vous ajouter comme coresponsable (Uploaders), car vous n'avez pas l'intention de participer régulièrement à ce paquet. Si cela est conforme avec la politique de votre équipe, vous pouvez procéder à un envoi normal sans être listé parmi les responsables (Maintainer ou Uploader). Dans ce cas, vous devriez commencer l'entrée du journal de modification (changelog) par la ligne suivante :

* Team upload.

5.12. Sauvetage de paquets

Le sauvetage de paquet est le processus permettant de sauver un paquet qui, tout en n'étant pas officiellement orphelin, semble peu ou complètement non entretenu. C’est une procédure moindre et plus rapide que de déclarer un paquet orphelin officiellement à l’aide des moyens de l’équipe MIA. Sauver un paquet n’est pas destiné à remplacer la gestion MIA et diffère en ce qu’elle n’implique aucunement l’activité complète de responsable. Cela gère plutôt la transition de responsabilité pour un seul paquet, n’affectant pas tout autre paquet, affiliation à Debian ou droits de téléversement (lorsque pertinents).

Il est a remarquer que le processus est seulement destiné à prendre fermement la responsabilité. Ne démarrez pas le processus de sauvetage de paquet sans la ferme intention d’entretenir le paquet pendant une période prolongée. Si vous voulez corriger certaines choses sans devenir responsable, vous devez utiliser le processus NMU, même si le paquet est susceptible d’être sauvé. Le processus NMU est expliqué dans Mises à jour indépendantes (NMU).

Une autre chose à se souvenir est qu’il n’est pas acceptable de détourner d’autres paquets. S'il est suivi, le processus de sauvetage vous aide à être sûr que votre initiative n’est pas un détournement, mais une procédure (officielle) de sauvetage, et vous pourrez réfuter toute allégation de détournement en faisant référence à ce processus. Grâce à ce processus, les nouveaux contributeurs ne devraient pas être effrayés de s’accaparer des paquets délaissés ou complètement abandonnés.

Le processus se déroule en deux phases. Premièrement, vous déterminez si le paquet en question est éligible au processus de sauvetage. Seulement après que l’éligibilité a été déterminée, vous pouvez démarrer la deuxième phase, le sauvetage effectif du paquet.

Pour des informations complémentaires, des principes et des FAQ sur le sauvetage de paquet, veuillez consulter la page Salvaging Packages sur le wiki de Debian.

5.12.1. Quand un paquet devient-il éligible au sauvetage de paquet ?

Un paquet devient éligible au sauvetage lorsqu’il est abandonné par le responsable actuel. Pour savoir qu’un paquet est réellement abandonné par son responsable, les indicateurs suivants donnent une idée sommaire sur ce qu’il faut rechercher :

• les NMU, spécialement s’il y a eu plusieurs NMU consécutifs ;

• les bogues concernant le paquet, sans réponse du responsable ;

• l’amont a publié plusieurs versions du paquet, mais malgré un dépôt de bogue en faisant la demande, elle n’a pas été empaquetée ;

• Il existe des problèmes de QA avec le paquet.

Vous devez vous fier à votre jugement pour déterminer si une combinaison de facteurs constitue un délaissement. En cas de désaccord du responsable, celui-ci doit seulement le signaler (voir ci-dessous). Si vous n’êtes pas sûr de votre jugement ou que vous vouliez simplement être du bon côté, il existe un ensemble de conditions plus précis (et conservateur) dans la page de wiki Package Salvaging. Ces conditions constituent le consensus actuel de Debian sur les critères de sauvetage. Dans tous les cas, vous devriez expliquer vos raisons de penser que le paquet est délaissé lorsque plus tard vous déposez un bogue « Intent to Salvage ».

5.12.2. Comment sauver un paquet ?

Si, et seulement si, un paquet a été déterminé comme éligible au sauvetage, n’importe quel responsable potentiel peut démarrer la procédure de sauvetage qui suit.

1. Ouvrez un bogue avec une sévérité « important » pour le paquet en question, exprimant votre intention de prendre la responsabilité du paquet. Pour cela, le titre du rapport doit débuter par ITS: package-name [3]. Sinon vous pouvez proposer de prendre la coresponsabilité du paquet. Lorsque vous ouvrez le bogue, vous devez informer tous les responsables, téléverseurs et si approprié, l’équipe d’empaquetage, explicitement en les ajoutant dans X-Debbugs-CC. De plus, si le ou les responsables semblent être généralement inactifs, veuillez informer l’équipe MIA en ajoutant également mia@qa.debian.org à X-Debbugs-CC. De même que l’expression explicite de l’intention de sauvetage, veuillez aussi prendre le temps de documenter votre évaluation de l’éligibilité dans le rapport de bogue, par exemple, en listant les critères utilisés et en ajoutant quelques données pour faciliter l’évaluation de la situation par d’autres ;

2. À ce stade, vous devez attendre au cas où des objections seraient soulevées. Le responsable, n’importe quel téléverseur actuel ou n’importe quel membre de l’équipe d’empaquetage concernée par le paquet en question peut objecter publiquement en réponse au bogue déposé sous 21 jours, et cela met fin au processus de sauvetage.

   Les responsables actuels peuvent être d’accord avec votre volonté de sauvetage en répondant (avec signature) publiquement au bogue. Ils peuvent proposer que vous deveniez coresponsable au lieu d’être l’unique responsable. Pour les paquets entretenus par une équipe, un membre de cette équipe peut accepter votre proposition de sauvetage en envoyant un avis signé d’accord au bogue ITS, ou autrement vous inviter à devenir un coresponsable du paquet. L’équipe peut exiger que le paquet reste sous sa tutelle, mais alors vous inviter à les rejoindre. Dans tous les cas, lorsque vous avez reçu le feu vert, vous pouvez téléverser le nouveau paquet immédiatement en tant que nouveau (co)responsable, sans avoir besoin d’utiliser la file d’attente DELAYED comme décrit dans la prochaine étape ;

3. Après 21 jours d’attente, si aucune réponse n’a été envoyée au bogue par le responsable, un téléverseur ou une équipe, vous pouvez envoyez la nouvelle publication du paquet dans la file d’attente DELAYED avec un délai minimal de sept jours. Vous devrez clore le bogue dans le changelog et vous devez aussi envoyer un nmudiff au bogue veillant que des copies soient envoyées au responsable et à tous les téléverseurs (y compris les équipes) du paquet en les mettant en CC (Copie conforme) dans le courriel au BTS.

   Durant le temps d’attente de la file DELAYED, les responsables peuvent accepter le sauvetage, faire un envoi eux-mêmes ou (demander à) annuler l’envoi. Ces deux dernières actions stopperont le processus de sauvetage, mais les responsables doivent répondre au bogue de sauvetage avec plus d’informations sur le pourquoi.

5.13. Maintenance collective

« Maintenance collective » est un terme décrivant le partage des devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette collaboration est presque toujours une bonne idée, car il en résulte généralement une meilleure qualité et un temps de correction de bogues plus court. Il est fortement recommandé que les paquets de priorité standard ou qui font partie de la base aient des coresponsables.

Habituellement, il y a un responsable principal et un ou plusieurs coresponsables. Le responsable principal est la personne dont le nom est indiqué dans le champ Maintainer du fichier debian/control. Les coresponsables sont tous les autres responsables, normalement listés dans le champ Uploaders du fichier debian/control.

Dans sa forme la plus simple, ajouter un nouveau coresponsable est assez facile :

• configurer le coresponsable avec droit d'accès aux sources à partir desquelles vous construisez le paquet. En général, cela implique que vous utilisez un système de gestion de versions en réseau, tel que Git. Salsa (voir salsa.debian.org : dépôts Git et plateforme de développement collaborative) fournit des dépôts Git parmi d'autres outils collaboratifs.

• ajouter les nom et adresse correctes du coresponsable au champ Uploaders dans le premier paragraphe du fichier debian/control ;

  Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
  

• en utilisant le suivi de paquets (Suivi de paquets Debian (Debian Package Tracker)), les coresponsables devraient s'inscrire eux-mêmes aux paquets source.

Une autre forme de maintenance collective est une maintenance en équipe, recommandée si vous gérez plusieurs paquets avec le même groupe de développeurs. Dans ce cas, les champs de responsable (Maintainer et Uploaders) de chaque paquet doivent être gérés avec attention. Il est conseillé de choisir entre les deux possibilités suivantes :

1. placer un membre de l'équipe comme responsable principal du paquet dans le champ Maintainer. En Uploaders, placer l'adresse de la liste de diffusion et les membres de l'équipe qui s'occupent du paquet ;

2. placer l'adresse de la liste de diffusion dans le champ Maintainer. En Uploaders, placer les membres de l'équipe qui s'occupent du paquet. Dans ce cas, vous devez vous assurer que la liste de diffusion peut recevoir les rapports de bogue sans interaction humaine (modération pour les non inscrits par exemple).

En tout cas, il faut éviter de placer automatiquement tous les membres de l'équipe dans le champ Uploaders. Cela encombre la vue d'ensemble des paquets d'un développeur (voir Vue d'ensemble des paquets d'un développeur) avec des paquets dont il ne s'occupe pas vraiment et donne la fausse impression d'un bon suivi. De même, les membres de l'équipe n'ont pas besoin de s'ajouter dans le champ Uploaders pour faire un envoi ponctuel, ils peuvent le faire en « envoi d'équipe » (voir NMU et envoi d'équipe). En revanche, c'est une mauvaise idée de garder un paquet avec seulement l'adresse de la liste de diffusion dans le champ Maintainer et sans Uploaders.

5.14. La distribution testing

5.14.1. Bases

Les paquets sont habituellement installés dans la distribution testing après avoir subi suffisamment de tests dans unstable.

Ils doivent être en synchronisation pour toutes les architectures et ne doivent pas avoir de dépendances qui les rendraient non installables ; ils doivent également être exempts de bogue critique pour la publication (« release-critical ») au moment où ils sont installés dans testing. Ainsi, testing devrait toujours être prête à devenir une version candidate pour la publication. Veuillez voir ci-dessous pour les détails.

5.14.2. Mise à jour depuis unstable

Les scripts de mise à jour de la distribution testing sont exécutés deux fois par jour, juste après l'installation des paquets mis à jour ; ces scripts sont appelés britney. Ils fabriquent les fichiers Packages pour la distribution testing, mais ils le font d'une manière intelligente pour éviter toute incohérence et essayer de n'utiliser que des paquets sans bogue.

L'inclusion d'un paquet d'unstable est soumise aux conditions suivantes :

• The package must have been available in unstable for a certain number of days, see Sélection de l’urgence du téléversement. Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous testing transition is taken into account;

• il ne doit pas introduire de nouveau bogue critique pour la publication (« RC bug » affectant la version disponible dans unstable, mais pas celle de testing) ;

• il doit être disponible pour toutes les architectures pour lesquelles il a déjà été construit dans unstable. Utilitaire dak ls permet de vérifier cette information ;

• il ne doit pas casser les dépendances d'un paquet déjà disponible dans testing ;

• les paquets dont il dépend doivent soit être déjà disponibles dans testing, soit être acceptés dans testing au même moment (et ils doivent remplir tous les critères nécessaires) ;

• l'état du projet. C'est-à-dire que les transitions automatiques sont arrêtées pendant le freeze (gel) de la distribution testing.

Pour savoir si un paquet a progressé ou non dans testing, veuillez voir la sortie du script de testing sur la page web de la distribution `testing <https://www.debian.org/devel/testing>`__ ou utilisez le programme grep-excuses du paquet devscripts. Pour rester informé de la progression de vos paquets dans testing, vous pouvez facilement le mettre dans une crontab 5.

Le fichier update_excuses ne donne pas toujours la raison précise pour laquelle un paquet est refusé ; il peut être nécessaire de la chercher soi-même en regardant ce qui serait cassé avec l'inclusion du paquet. La page web de la distribution testing donne plus d'informations sur les problèmes courants pouvant occasionner cela.

Parfois, certains paquets n'entrent jamais dans testing parce que le jeu des interrelations est trop compliqué et ne peut être résolu par le script. Voir ci-dessous pour des détails.

Des analyses de dépendances plus avancées sont présentées sur https://release.debian.org/migration/ — mais, attention, cette page affiche également des dépendances de construction qui ne sont pas prises en compte par britney.

5.14.2.1. Désynchronisation

Pour le script de migration de testing, périmé signifie : il y a différentes versions dans unstable pour les architectures publiées (sauf les architectures dans outofsync_arches ; outofsync_arches est la liste des architectures qui sont abandonnées (dans britney.py), mais actuellement la liste est vide). Le caractère périmé n'a absolument rien à voir avec les architectures de ce paquet dans testing.

Considérons cet exemple :

	alpha	arm
testing	1	-
unstable	1	2

Le paquet est désynchronisé pour alpha dans unstable et n'entrera pas dans testing. Supprimer le paquet de testing n'aiderait en rien, le paquet serait toujours désynchronisé pour alpha et ne se propagerait pas dans testing.

Cependant, si ftp-master supprime un paquet d'unstable (ici pour arm) :

	alpha	arm	hurd-i386
testing	1	1	-
unstable	2	-	1

Dans ce cas, le paquet est synchronisé pour toutes les architectures de version dans unstable (et l'architecture supplémentaire hurd-i386 ne compte pas, car ce n'est pas une architecture de publication).

Quelquefois, la question est soulevée de savoir s'il est possible de permettre à des paquets de passer dans testing alors qu'ils ne sont pas encore construits pour toutes les architectures : non. Simplement non. (Excepté si vous êtes responsable de glibc ou équivalent).

5.14.2.2. Suppression de testing

Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre paquet : cela ne se produit que pour permettre à un autre paquet d'entrer, ce dernier doit être prêt pour tous les autres critères. Par exemple, si un paquet a ne peut pas être installé avec la nouvelle version de b, alors a peut être supprimé pour permettre l'entrée de b.

Bien sûr, il existe une autre raison pour supprimer un paquet de testing : le paquet est trop bogué (et avoir un seul bogue critique pour la publication est suffisant pour être dans cet état).

De plus, si un paquet a été supprimé d'unstable et que plus un seul paquet de testing n'en dépend, il sera alors automatiquement supprimé.

5.14.2.3. Dépendances circulaires

Une situation mal gérée par britney est si un paquet a dépend de la nouvelle version d'un paquet b et vice versa.

Voici un exemple :

	testing	unstable
a	1 ; dépend de : b=1	2 ; dépend de : b=2
b	2 ; dépend de : a=1	2 ; dépend de : a=2

Aucun des paquets a et b ne sera considéré pour une mise à jour.

Actuellement, cela nécessite un coup de pouce manuel de l'équipe de publication. Veuillez les contacter à l'adresse debian-release@lists.debian.org si cela se produit pour l'un de vos paquets.

5.14.2.4. Influence d'un paquet dans testing

En général, rien n'est indiqué par l'état d'un paquet dans testing pour une transition de la versions suivante d'unstable vers testing, avec deux exceptions : la première si le nombre de bogues critiques pour la publication diminue, il peut entrer même s'il comporte encore des bogues critiques. La seconde exception, c'est si la version du paquet dans testing est désynchronisée sur les différentes architectures : alors une architecture pourrait seulement être mise à niveau vers la version du paquet source ; néanmoins, cela peut se produire seulement si auparavant le passage du paquet a été forcé, si l'architecture est dans outofsync_arches ou s'il n'y avait aucun paquet binaire de cette architecture présent dans unstable durant la migration de testing.

En résumé, cela signifie : la seule influence qu'un paquet de testing a sur la nouvelle version du même paquet est que la nouvelle version peut entrer plus facilement.

5.14.2.5. Détails

Si vous êtes intéressés par les détails, voici quelques informations sur le fonctionnement de britney.

Les paquets sont examinés pour savoir si ce sont des candidats valables. Cela génère les dispenses de mise à jour (« update excuses »). Les raisons habituelles pour lesquelles un paquet n'est pas considéré sont la jeunesse du paquet, le nombre de bogues critiques pour la publication et la désynchronisation pour certaines architectures. Pour cette partie de britney, les responsables de publication ont des marteaux de toute taille, appelés coups de pouce (« hints », voir ci-dessous) pour forcer britney à examiner un paquet.

Maintenant, la partie la plus complexe se produit : britney tente de mettre à jour testing avec des candidats valables. Pour ce faire, britney essaye d'ajouter chaque candidat valable à la distribution testing. Si le nombre de paquets non installables dans testing n'augmente pas, le paquet est accepté. À partir de là, le paquet accepté est considéré comme partie de testing, de telle sorte qu'il sera considéré dans les tests suivants d'installabilité. Avant et après cette partie, certains coups de pouce (« hints ») de l'équipe de publication sont traités.

Pour obtenir plus de précisions, vous pouvez consulter https://release.debian.org/britney/update_output/.

Les coups de pouce (« hints ») sont disponibles sur https://release.debian.org/britney/hints/, qui contient aussi une description. Avec les coups de pouce, l'équipe en charge de la publication de Debian peut bloquer ou débloquer des paquets, faciliter ou forcer le passage de paquets dans testing, enlever des paquets de testing, approuver des envois vers les Mises à jour directes dans testing ou outrepasser l'urgence.

5.14.3. Mises à jour directes dans testing

La distribution testing est remplie de paquets en provenance d'unstable selon des règles expliquées ci-dessus. Cependant, dans certains cas, il est nécessaire d'envoyer des paquets construits seulement pour testing. Pour cela, vous pouvez envoyer vos paquets vers testing-proposed-updates.

Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement, ils doivent passer entre les mains des responsables de distribution. Vous devez donc avoir une bonne raison pour les y envoyer. Pour savoir ce que représente une bonne raison aux yeux des responsables de publication, vous devriez lire les instructions qu'ils envoient régulièrement sur debian-devel-announce@lists.debian.org.

Vous ne devriez pas envoyer de paquet à testing-proposed-updates quand vous pouvez le mettre à jour par unstable. Si vous ne pouvez faire autrement (par exemple, parce que vous avez une nouvelle version de développement dans unstable), vous pouvez utiliser cette fonction. Même si un paquet est gelé, des mises à jour par unstable sont possibles si l'envoi dans unstable ne crée pas de nouvelles dépendances.

Les numéros de version sont habituellement choisis en ajoutant +debXuY, où X est le numéro de publication majeure de Debian et Y est un compteur démarrant à 1, par exemple, 1:2.4.3-4+deb12u1.

Veuillez vous assurer de n'avoir oublié aucun des éléments suivants lors de votre envoi :

• vérifiez que le paquet doit vraiment aller dans testing-proposed-updates, et ne peut pas passer par unstable ;

• vérifiez de n'avoir intégré qu'un minimum de changements ;

• vérifiez d'avoir ajouté une explication appropriée dans le journal de modification (changelog) ;

• vérifiez d'avoir ajouté les Noms de code des distributions de testing (par exemple, trixie) comme distribution cible ;

• vérifiez d'avoir construit et testé votre paquet dans testing, et non dans unstable ;

• vérifiez que le numéro de version est plus élevé que les versions de testing et de testing-proposed-updates, et moins élevé que celui d'unstable ;

• demandez l'autorisation d'envoi aux responsables de publication ;

• après l'envoi et la construction réussie sur toutes les plates-formes, contactez l'équipe de publication à debian-release@lists.debian.org et demandez-leur d'approuver votre envoi.

5.14.4. Foire aux questions

5.14.4.1. Quels sont les bogues bloquant l'intégration dans la version stable et comment sont-ils pris en compte ?

Tous les bogues de gravité assez élevée sont par défaut considérés comme bloquant l'intégration du paquet dans la version stable ; actuellement, ce sont les bogues critical (critique), grave (grave) et serious (sérieux).

Certains bogues sont supposés avoir un impact sur la probabilité d'un paquet a être diffusé dans la version stable de Debian : en général, si un paquet a des bogues bloquants, il n'ira pas dans testing, et par conséquent, ne pourra pas être diffusé dans stable.

Le décompte des bogues d'unstable inclut tous les bogues critiques pour la publication marqués pour s'appliquer à des combinaisons de paquet/version disponibles dans unstable pour une architecture concernée par la publication. Le décompte des bogues de testing est défini de façon analogue.

5.14.4.2. Comment l'installation d'un paquet dans testing peut-elle casser d'autres paquets ?

La structure des archives de la distribution est faite de telle façon qu'elles ne peuvent contenir qu'une version d'un paquet ; un paquet est défini par son nom. Donc, quand le paquet source acmefoo est installé dans testing avec ses paquets binaires acme-foo-bin, acme-bar-bin, libacme-foo1 et libacme-foo-dev, l'ancienne version est supprimée.

Cependant, l'ancienne version pouvait fournir à un paquet binaire un vieux soname d'une bibliothèque, comme libacme-foo0. Supprimer l'ancien acmefoo va supprimer libacme-foo0, ce qui va casser tout paquet qui en dépend.

Évidemment, cela touche principalement des paquets qui fournissent des jeux variables de paquets binaires pour différentes versions (principalement des bibliothèques). Cependant, cela va aussi concerner des paquets sur lesquels une dépendance versionnée du type ==, <=, ou << a été déclarée.

Quand le jeu de paquets binaires fournis par un paquet source change de cette façon, tous les paquets qui dépendent des anciens binaires doivent être mis à jour pour dépendre plutôt de la nouvelle version. Comme l'installation d'un tel paquet source dans testing casse tous les paquets qui en dépendent dans testing, une attention particulière doit y être portée : tous les paquets en dépendant doivent être mis à jour et prêts à être installés eux-mêmes pour ne pas casser et, une fois que tout est prêt, une intervention manuelle des responsables de publication est normalement requise.

Si vous avez des problèmes avec des groupes compliqués de paquets comme cela, demandez de l'aide sur debian-devel@lists.debian.org ou debian-release@lists.debian.org.

[1]

Reportez-vous à la Charte Debian (« Debian Policy Manual ») pour savoir dans quelle section un paquet doit être classé.

[2]

Par le passé, ces NMU utilisaient le numéro de troisième niveau de la partie Debian de la révision pour indiquer l'état de leur recompilation particulière ; cependant, cette syntaxe était ambiguë pour les paquets natifs et ne permettait pas d'ordonner correctement les NMU de recompilation particulière, les NMU source et les NMU de sécurité sur le même paquet, elle a donc été abandonnée en faveur de cette nouvelle syntaxe.

[3]

ITS est une abréviation pour "Intend to Salvage".

[4]

Though, if a package still is in the upload queue and hasn't been moved to Incoming yet, it can be removed. (see Envois sur ftp-master)

5.15. The Stable backports archive

5.15.1. Bases

Once a package reaches the testing distribution, it is possible for anyone with upload rights in Debian (see below about this) to build and upload a backport of that package to stable-backports, to allow easy installation of the version from testing onto a system that is tracking the stable distribution.

One should not upload a version of a package to stable-backports until the matching version has already reached the testing archive.

5.15.2. Exception to the testing-first rule

The only exception to the above rule, is when there's an important security fix that deserves a quick upload: in such a case, there is no need to delay an upload of the security fix to the stable-backports archive. However, it is strongly advised that the package is first fixed in unstable before uploading a fix to the stable-backports archive.

5.15.3. Who can maintain packages in the stable-backports archive?

It is not necessarily up to the original package maintainer to maintain the stable-backports version of the package. Anyone can do it, and one doesn't even need approval from the original maintainer to do so. It is however good practice to first get in touch with the original maintainer of the package before attempting to start the maintenance of a package in stable-backports. The maintainer can, if they wish, decide to maintain the backport themselves, or help you doing so. It is not uncommon, for example, to apply a patch to the unstable version of a package, to facilitate its backporting.

5.15.4. When can one start uploading to stable-backports?

The new stable-backports is created before the freeze of the next stable suite. However, it is not allowed to upload there until the very end of the freeze cycle. The stable-backports archive is usually opened a few weeks before the final release of the next stable suite, but it doesn't make sense to upload until the release has actually happened.

5.15.5. How long must a package be maintained when uploaded to stable-backports?

The stable-backports archive is maintained for bugs and security issues during the whole life-cycle of the Debian stable suite. Therefore, an upload to stable-backports, implies a willingness to maintain the backported package for the duration of the stable suite, which can be expected to be about 3 years from its initial release.

The person uploading to backports is also supposed to maintain the backported packages for security during the lifetime of stable.

It is to be noted that the stable-backports isn't part of the LTS or ELTS effort. The stable-backports FTP masters will close the stable-backports repositories for uploads once stable reaches end-of-life (ie: when stable becomes maintained by the LTS team only). Therefore there won't be any maintenance of packages from stable-backports after the official end of life of the stable suite, as uploads will not be accepted.

5.15.6. How often shall one upload to stable-backports?

The packages in backports are supposed to follow the developments that are happening in Testing. Therefore, it is expected that any significant update in testing should trigger an upload into stable-backports, until the new stable is released. However, please do not backport minor version changes without user visible changes or bugfixes.

5.15.7. How can one learn more about backporting?

You can learn more about how to contribute directly on the backport web site.

It is also recommended to read the Frequently Asked Questions (FAQ).

6. Meilleures pratiques d'empaquetage

La qualité de Debian est largement due à la Charte Debian qui définit explicitement les exigences de base que tous les paquets Debian doivent satisfaire. Cependant, il existe également une expérience générale partagée qui va bien au delà de la Charte Debian et constitue une somme d'années d'expérience dans l'empaquetage. De nombreux contributeurs talentueux ont créé d'excellents outils qui peuvent vous aider, en tant que mainteneur Debian, à créer et maintenir des paquets d'excellente qualité.

Ce chapitre rassemble les meilleures pratiques pour les responsables Debian. La majorité de son contenu est constituée de recommandations plus que d'obligations. Il s'agit essentiellement d'informations subjectives, d'avis et de pointeurs, rassemblés par les développeurs Debian. Il est conseillé d'y choisir ce qui vous convient le mieux.

6.1. Meilleures pratiques pour debian/rules

Les recommandations qui suivent s'appliquent au fichier debian/rules. Comme ce fichier contrôle le processus de construction des paquets et fait le choix des fichiers qui entreront dans ce paquet (directement ou indirectement), il s'agit du fichier dont les responsables s'occupent généralement le plus.

6.1.1. Scripts d'assistance

La motivation pour utiliser des scripts d'assistance dans debian/rules est de permettre aux mainteneurs de définir puis utiliser une logique commune pour de nombreux paquets. Si on prend par exemple l'installation d'entrées de menu, il est nécessaire de placer le fichier dans /usr/share/menu (ou /usr/lib/menu pour les fichiers de menu exécutables, si besoin), puis d'ajouter des commandes aux scripts des responsables pour ajouter ou enlever les entrées de menu. Comme cette action est commune à de très nombreux paquets, pourquoi faudrait-il que chaque responsable doivent réécrire ses propres méthodes, bogues compris ? De plus, si jamais le répertoire des menus venait à changer, chaque paquet devrait être modifié.

Les scripts d'assistance s'occupent de ce type de tâche. À condition de suivre les conventions utilisées par le script d'assistance, celui-ci s'occupe de tous les détails. Les modifications dans la Charte peuvent alors être implémentées dans le script d'assistance et les paquets n'ont plus qu'à être reconstruits sans autre modification.

Aperçu des outils du responsable Debian contient un certain nombre d'assistants variés. Le système le plus répandu et (de l'avis général) le plus adapté est debhelper. Des systèmes antérieurs, tels que debmake, étaient monolithiques : ils ne permettaient pas de choisir quelle partie de l'assistant serait utile et obligeaient à se servir de l'ensemble de l'assistant. A contrario, debhelper est constitué d'un grand nombre de petits programmes dh_* différents. Par exemple, dh_installman installe et compresse les pages de manuel, dh_installmenu installe les fichiers de menu, et ainsi de suite. En conséquence, il offre la possibilité d'utiliser certains des scripts d'assistance tout en conservant des commandes manuelles dans debian/rules.

Pour démarrer avec debhelper, il est conseillé de lire debhelper 1 et de consulter les exemples fournis avec le paquet. dh_make, fourni avec le paquet dh-make (voir dh-make) peut être utilisé pour convertir un paquet source originel en paquet géré par debhelper. Cette méthode rapide ne doit cependant pas se substituer à une compréhension individuelle des commandes dh_*. Si vous utilisez un assistant, vous devez prendre le temps de le connaître, pour comprendre ses besoins et son comportement.

6.1.2. Séparation des correctifs (« patches ») en plusieurs fichiers

Les paquets complexes ont souvent de nombreux bogues qui doivent être gérés par le responsable. Si certains de ces bogues sont corrigés par des modifications effectuées directement dans le code source, sans discernement, il peut devenir difficile de retrouver l'origine et la motivation de ces correctifs. Cela peut également rendre bien plus complexe l'intégration d'une nouvelle version amont qui pourrait inclure certains de ces correctifs (mais pas tous). Il est en effet alors quasiment impossible de reprendre le jeu initial de changements (par exemple dans le fichier .diff.gz) et supprimer ceux qui correspondent à des correctifs appliqués par le responsable amont.

Heureusement, avec le format source « 3.0 (quilt) », il est dorénavant possible de séparer des correctifs (« patches ») sans avoir à modifier debian/rules pour configurer un système de correctifs. Les correctifs sont conservés dans debian/patches/ et, lorsque le paquet source est dépaqueté (« unpacked »), les correctifs énumérés dans debian/patches/series sont automatiquement appliqués. Comme le nom le suggère, les correctifs peuvent être gérés avec quilt.

Avec l'ancien format source « 1.0 », il est aussi possible de séparer les correctifs, mais un système de correctif dédié doit être utilisé : les correctifs individualisés sont embarqués dans le fichier général de correctifs Debian (.diff.gz), en général à l'intérieur du répertoire debian/. La seule différence est que ces correctifs ne sont pas appliqués directement par dpkg-source, mais par la règle build de debian/rules, à travers une dépendance à la règle patch. À l'inverse, les correctifs sont retirés par la règle clean, à travers une dépendance à la règle unpatch.

quilt est l'outil recommandé pour ce besoin. Il effectue l'ensemble des actions mentionnées précédemment et offre la possibilité de gérer des ensembles de correctifs. Veuillez regarder le paquet quilt pour plus d'informations.

6.1.3. Paquets binaires multiples

Un paquet source unique construira souvent plusieurs paquets binaires, soit pour fournir plusieurs variantes du même logiciel (par exemple, le paquet source vim) ou pour créer plusieurs petits paquets à la place d'un seul grand paquet (par exemple, l'utilisateur peut installer uniquement le sous-ensemble nécessaire et ainsi économiser de l'espace disque, voir par exemple le paquet source libxml2).

Le second cas est simple à gérer dans le fichier debian/rules. Il suffit de déplacer les fichiers nécessaires depuis le répertoire de construction vers l'arborescence temporaire du paquet. Cela peut se faire avec les commandes install ou dh_install du paquet debhelper. Veillez alors à contrôler les différentes permutations des paquets, afin de pouvoir indiquer les dépendances inter-paquets appropriées dans debian/control.

Le premier cas est plus délicat à gérer, car il implique des recompilations multiples du même logiciel avec différentes options de configuration. Le paquet source vim en est un exemple, l'ensemble des actions dans le fichier debian/rules étant géré manuellement.

6.2. Meilleures pratiques pour debian/control

Les conseils qui suivent sont destinés au fichier debian/control. Ils complètent la Charte Debian concernant les descriptions de paquets.

La description d'un paquet telle que définie par le champ correspondant du fichier control, comprend à la fois le résumé et la description longue du paquet. Conseils généraux pour les descriptions de paquets donne des indications communes à ces deux parties, Résumé, ou description courte, d'un paquet donne des indications spécifiques pour le résumé et Description longue donne des indications pour la description.

6.2.1. Conseils généraux pour les descriptions de paquets

La description d'un paquet doit être écrite pour son utilisateur moyen, c'est-à-dire la personne qui utilisera et tirera profit du paquet. Par exemple, les paquets de développement sont destinés aux développeurs et leur description peut comporter des détails techniques alors que les applications d'usage plus général, telles que les éditeurs, doivent avoir une description accessible à tout utilisateur.

Un examen général des descriptions de paquets tend à montrer que la plupart d'entre elles ont une orientation fortement technique et ne sont donc pas destinées à l'utilisateur moyen. Sauf dans le cas de paquets destinés à des spécialistes, cela doit être considéré comme un problème.

Une recommandation pour rester accessible à tout utilisateur est d'éviter l'utilisation de jargon. Il est déconseillé de faire référence à des applications ou environnements qui pourraient être inconnus de l'utilisateur : parler de GNOME ou KDE est correct, car la plupart des utilisateurs sont familiers avec ces termes, mais parler de GTK ne l'est pas. Il est préférable de supposer que le lecteur n'aura pas de connaissance du sujet et, si des termes techniques doivent être utilisés, ils doivent être expliqués.

Il est conseillé de rester objectif. Les descriptions de paquets ne sont pas une plaquette publicitaire, quelles que soient vos opinions personnelles. Le lecteur peut très bien ne pas avoir les mêmes centres d'intérêt que vous.

Les références aux noms d'autres logiciels, de protocoles, normes ou spécifications doivent utiliser leur forme canonique si elle existe. Par exemple, utilisez « X Window System », « X11 » ou « X », mais pas « X Windows », « X-Windows », ou « X Window ». Utilisez « GTK » et non « GTK+ » ou « gtk », « GNOME » et non « Gnome », « PostScript » et non « Postscript » ou « postscript ».

Si vous rencontrez des difficultés pour écrire la description d'un paquet, vous pouvez demander de l'aide ou une relecture sur debian-l10n-english@lists.debian.org.

6.2.2. Résumé, ou description courte, d'un paquet

La Charte indique que la ligne de résumé (la description courte) doit être concise, ne doit pas répéter le nom du paquet, mais doit être informative.

La description courte est une expression qui décrit le paquet, pas une phrase complète, donc les conventions de ponctuation sont inappropriées : pas besoin de commencer par une majuscule ou de finir par un point. Elle devrait éviter également la présence d'article défini ou indéfini — « a », « an », ou « the ». Par exemple :

Package: libeg0
Description: exemplification support library

Techniquement, c'est une phrase nominale sans article, par opposition à une phrase verbale. Une bonne vérification est de pouvoir remplacer le nom du paquet et son résumé dans la phrase :

Le paquet nom fournit {un,une,le,la,l',du,de la} résumé (« the package nom provides {a,an,the,some} résumé »).

Les ensembles de paquets peuvent utiliser un schéma alternatif qui divise la description courte en deux parties, la première une description de l'ensemble et la seconde un résumé du rôle du paquet dans l'ensemble :

Package: eg-tools
Description: simple exemplification system (utilities)

Package: eg-doc
Description: simple exemplification system - documentation

Ces descriptions courtes suivent un modèle modifié. Quand un paquet « nom » possède une description courte « ensemble (rôle) » ou « ensemble - rôle », les éléments peuvent être placés dans la phrase :

Le paquet nom fournit {un,une,le,la,l'} rôle pour {le,la,l'} ensemble (« the package nom provides {a,an,the} rôle for the ensemble »).

6.2.3. Description longue

La description longue est l'information principale disponible pour les utilisateurs avant d'installer un paquet. Elle devrait fournir toutes les informations nécessaires pour déterminer si le paquet doit être installé. Elle complète le résumé qui est donc supposé avoir été lu précédemment.

La description longue est constituée de phrases complètes.

Le premier paragraphe de cette description devrait tenter de répondre aux questions suivantes : « Que fait ce paquet ? », « Dans quelle tâche aidera-t-il l'utilisateur ? ». Il est important que cette description se fasse de la manière la moins technique possible, sauf si le public auquel est destiné le paquet est par définition technique.

Les descriptions longues de paquets associés, par exemple construits à partir du même paquet source, peuvent partager des paragraphes afin d'améliorer la cohérence et de réduire la charge de travail pour les traducteurs, mais il faut qu'il y ait au moins un paragraphe distinct qui décrive le rôle spécifique du paquet.

Les paragraphes suivants devraient répondre aux questions : « Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? », « Quelles autres fonctionnalités ce paquet apporte-t-il ? », « Quelles fonctionnalités et défauts comporte-t-il par rapport à d'autres paquets (par exemple, « si vous avez besoin de X, utilisez plutôt Y ») ? », « Ce paquet est-il lié à d'autres paquets d'une manière non gérée par le système de gestion des paquets (par exemple, « cela est le client destiné au serveur toto ») ? ».

Veillez à éviter les erreurs d'orthographe et de grammaire. Vérifiez l'orthographe avec un outil adapté. Les deux programmes ispell et aspell comportent un mode spécial permettant de contrôler un fichier debian/control files :

ispell -d american -g debian/control

aspell -d en -D -c debian/control

Les utilisateurs attendent en général des descriptions de paquets les réponses aux questions suivantes.

• Que fait ce paquet ? S'il s'agit d'un additif à un autre paquet, la description de cet autre paquet doit y être reprise.

• Pourquoi ai-je besoin de ce paquet ? Cela est lié à la remarque précédente, de manière différente (cela est un agent utilisateur pour le courrier électronique, avec une interface rapide et pratique vers PGP, LDAP et IMAP et les fonctionnalités X, Y ou Z).

• Si ce paquet ne doit pas être installé seul, mais est installé par un autre paquet, cela devrait être mentionné.

• Si le paquet est expérimental ou ne doit pas être utilisé pour toute autre raison et que d'autres paquets doivent être utilisés à la place, cela doit également être mentionné.

• En quoi ce paquet diffère-t-il de ses concurrents ? Est-il une meilleure implémentation ? A-t-il plus de fonctionnalités ? Des fonctionnalités différentes ? Pourquoi devrais-je choisir ce paquet ?

6.2.4. Page d'accueil amont

Il est recommandé d'ajouter l'URL d'accès à la page d'accueil du paquet dans le champ Homepage de la section Source du fichier debian/control. L'ajout de cette information à la description même du paquet est une pratique considérée obsolète.

6.2.5. Emplacement du système de gestion de versions

Des champs supplémentaires permettent d'indiquer l'emplacement du système de gestion de versions dans debian/control.

6.2.5.1. Vcs-Browser

La valeur de ce champ doit être une URL https:// pointant sur la copie navigable par le web du dépôt de gestion de versions utilisé pour la maintenance du paquet, s'il est disponible.

Cette information est destinée à l'utilisateur final qui voudrait parcourir le travail en cours sur le paquet (par exemple à la recherche d'un correctif qui corrige un bogue marqué pending (en attente) dans le système de suivi des bogues.

6.2.5.2. Vcs-*

Value of this field should be a string identifying unequivocally the location of the Version Control System repository used to maintain the given package, if available. * identifies the Version Control System; currently the following systems are supported by the package tracking system: arch, bzr (Bazaar), cvs, darcs, git, hg (Mercurial), mtn (Monotone), svn (Subversion).

Cette information est destinée aux utilisateurs qui ont une connaissance suffisante du système de gestion de versions et qui veulent construire une version à jour du paquet depuis les sources du système de suivi. Une autre utilisation possible de cette information pourrait être la construction automatique de la dernière version, dans le système de suivi, d'un paquet donné. À cet effet, l'emplacement pointé devrait éviter d'être lié à une version spécifique et pointer vers la branche principale de développement (pour les systèmes qui ont un tel concept). De plus, l'emplacement indiqué doit être accessible à l'utilisateur final, par exemple en indiquant une adresse d'accès anonyme au dépôt, plutôt qu'une version accessible par SSH.

L'exemple qui suit montre une instance de ce champ pour un dépôt Git du paquet vim. Veuillez noter que l'URL a la forme https:// (au lieu de ssh://). Une utilisation des champs Vcs-Browser et Homepage, décrits précédemment, est aussi indiquée.

Source: vim
<snip>
Vcs-Git: https://salsa.debian.org/vim-team/vim.git
Vcs-Browser: https://salsa.debian.org/vim-team/vim
Homepage: https://www.vim.org

Maintaining the packaging in a version control system, and setting a Vcs-* header is good practice and makes it easier for others to contribute changes.

Almost all packages in Debian that use a version control system use Git; if you create a new package, using Git is a good idea simply because it's the system that contributors will be familiar with.

DEP-14 defines a common layout for Debian packages.

6.3. Meilleures pratiques pour debian/changelog

Les indications de cette partie complètent la Charte Debian pour ce qui concerne les fichiers de journaux des modifications (« changelog »).

6.3.1. Entrées de journalisation utiles

Le journal des modifications (« changelog ») présente uniquement les changements intervenus dans la version courante. Il est suggéré de mettre l'accent sur les modifications visibles ou affectant potentiellement les utilisateurs, réalisées depuis la version précédente.

Il est conseillé de mettre l'accent sur ce qui a été modifié, plutôt que comment, par qui et quand elle a été réalisée. Cela dit, il est conseillé, par courtoisie, d'indiquer les auteurs qui ont apporté une aide significative à la maintenance du paquet (par exemple lorsque ces personnes ont envoyé des correctifs).

Il n'est pas indispensable d'indiquer les détails des modifications triviales. Il est également possible de grouper plusieurs modifications sur une même entrée. Cependant, évitez une documentation trop concise pour les modifications majeures. Il est particulièrement conseillé d'être très clair sur les modifications qui affectent le comportement du programme. Pour des explications plus détaillées, vous pouvez aussi utiliser le fichier README.Debian.

Utilisez un anglais simple que la majorité des lecteurs puissent comprendre. Évitez les abréviations et le jargon technique lorsque des modifications permettent la clôture de bogues. Cela est vrai notamment quand vous pensez que les utilisateurs qui les ont envoyés n'ont pas de connaissances techniques importantes. Une formulation polie est à préférer et la vulgarité à prohiber.

Il est parfois souhaitable de faire précéder les entrées du journal des modifications par les noms des fichiers modifiés. Cependant, rien n'oblige à mentionner le moindre fichier modifié, notamment si la modification est simple ou répétitive. L'utilisation de caractères joker est possible.

Ne faites pas de suppositions lorsque vous faites référence à un bogue. Indiquez quel était le problème, comment il a été corrigé et ajoutez la chaîne closes: #nnnnn. Veuillez consulter Fermeture des rapports de bogue lors des mises à jour pour plus d'informations.

6.3.2. Sélection de l’urgence du téléversement

The release team have indicated that they expect most uploads to unstable to use urgency=medium. That is, you should choose urgency=medium unless there is some particular reason for the upload to migrate to testing more quickly or slowly (see also Mise à jour depuis unstable). For example, you might select urgency=low if the changes since the last upload are large and might be disruptive in unanticipated ways.

The delays are currently 2, 5 or 10 days, depending on the urgency (high, medium or low). The actual numbers are actually controled by the britney configuration which also includes accelerated migrations when Autopkgtest passes.

6.3.3. Idées reçues sur les entrées de journalisation

Les entrées de journal des modifications ne devraient pas documenter les points spécifiques de la réalisation du paquet (« si vous cherchez le fichier toto.conf, il est situé dans /etc/titi »), car les administrateurs et les utilisateurs sont censés avoir l'habitude de la façon dont ces aspects sont traités sur un système Debian. Pensez, par contre, à documenter la modification de l'emplacement d'un fichier de configuration.

Les seuls bogues fermés par une entrée de journal de modifications devraient être ceux qui sont corrigés par la version correspondante du paquet. Fermer de cette manière des bogues qui n'ont aucun rapport avec la nouvelle version est considéré comme une mauvaise habitude. Veuillez consulter Fermeture des rapports de bogue lors des mises à jour.

Les entrées du journal des modifications ne devraient pas être utilisées pour des discussions variées avec les émetteurs des rapports de bogue (par exemple : « je n'ai pas d'erreur de segmentation quand je lance toto avec l'option titi, merci d'envoyer plus d'informations »). De même, les considérations générales sur la vie, l'univers et le reste (« désolé, cet envoi m'a pris plus longtemps que prévu, mais j'avais un rhume ») ou encore des demandes d'aide (« la liste de bogues de ce paquet est très longue, merci de me donner un coup de main ») sont à éviter. Ces mentions ne seront généralement pas remarquées par leur public potentiel et peuvent ennuyer les personnes qui cherchent à lire les modifications concrètes du paquet. Voir Réponses aux bogues pour plus d'informations sur l'utilisation du système de gestion des bogues.

Une tradition assez ancienne veut que les bogues corrigés dans les NMU soient pris en compte dans la première entrée du journal des modifications d'une nouvelle version construite par le responsable. Depuis l'existence du suivi de version pour le système de gestion de bogues, cette pratique est obsolète à condition de conserver les entrées du journal des modifications des NMU. Il est éventuellement possible de simplement mentionner les NMU dans votre propre entrée de journal des modifications.

6.3.4. Erreurs usuelles dans les entrées de journalisation

Les exemples suivants sont des erreurs usuelles ou des exemples de mauvaises pratiques dans le style des entrées de journaux de modifications (NdT : le texte est volontairement laissé non traduit).

* Fixed all outstanding bugs.

Cela ne donne évidemment aucune indication au lecteur.

* Applied patch from Jane Random.

Que faisait ce correctif ?

* Late night install target overhaul.

Qu'est-ce que cela a amené ? Est-ce que la mention du fait que cela ait été fait tard la nuit doit nous alerter sur la probable mauvaise qualité du code ?

* Fix vsync fw glitch w/ ancient CRTs.

Trop d'acronymes (que signifie « fw », « firmware » ?), et la nature réelle du problème n'est pas claire, ou comment il a été corrigé.

* This is not a bug, closes: #nnnnnn.

Il est inutile de faire un nouvel envoi de paquet pour envoyer cette information. Il suffit simplement d'utiliser le système de suivi des bogues. De plus, aucune explication n'est donnée sur les raisons qui font que le problème n'est pas un bogue.

* Has been fixed for ages, but I forgot to close; closes: #54321.

Si, pour une raison donnée, vous avez omis de mentionner un numéro de bogue dans une entrée précédente, ce n'est pas grave : il suffit de clore le bogue normalement dans le système de suivi des bogues. Il est inutile de changer le journal des modifications si on suppose que les explications sur la correction du bogue sont dans le bogue lui-même (cela s'applique également au suivi des bogues des auteurs amont : il est inutile de suivre, dans le journal des modifications, les bogues qu'ils ont corrigés depuis longtemps).

* Closes: #12345, #12346, #15432

Où est la description ? Si vous ne trouvez pas de message suffisamment explicite, vous pouvez au moins utiliser le titre du rapport de bogue.

6.3.5. Complément des journaux de modifications dans les fichiers NEWS.Debian

Les nouvelles importantes sur les modifications survenues dans un paquet peuvent être placées dans des fichiers NEWS.Debian. Ces nouvelles seront affichées par des outils tels que apt-listchanges avant tout le reste des modifications. Cette méthode est à privilégier pour diffuser aux utilisateurs d'un paquet les modifications importantes qu'il subit. Il est préférable de l'utiliser plutôt que des notes debconf, car ce système permet de revenir lire les fichiers NEWS.Debian après l'installation. Il est également préférable de faire la liste des modifications majeures dans README.Debian, car un utilisateur peut assez facilement ne pas remarquer l'affichage d'une note debconf (Ndt : a contrario, les fichiers NEWS.Debian ne peuvent être traduits).

Le format de ce fichier est analogue à un journal de modifications Debian, mais n'utilise pas d'astérisque et chaque nouveau message utilise un paragraphe complet plutôt que les mentions succinctes qui seraient utilisées dans le journal des modifications. Il est conseillé de traiter le fichier avec dpkg-parsechangelog, ce qui permet d'en vérifier la mise en forme, car il ne sera pas automatiquement modifié pendant la construction du paquet, contrairement au journal des modifications. Voici un exemple de fichier NEWS.Debian réel :

cron (3.0pl1-74) unstable; urgency=low

    The checksecurity script is no longer included with the cron package:
    it now has its own package, checksecurity. If you liked the
    functionality provided with that script, please install the new
    package.

 -- Steve Greenland <stevegr@debian.org>  Sat,  6 Sep 2003 17:15:03 -0500

Le fichier NEWS.Debian est installé sous le nom /usr/share/doc/paquet/NEWS.Debian.gz. Il est compressé et porte toujours ce nom même pour les paquets Debian natifs. Si vous utilisez debhelper, dh_installchangelogs installera les fichiers debian/NEWS automatiquement.

À la différence des journaux de modifications, vous n'avez pas besoin de mettre NEWS.Debian à jour à chaque nouvelle version. Il est suffisant de le mettre à jour quand une information importante doit être diffusée aux utilisateurs. Si vous n'avez pas d'information importante à diffuser, il n'est pas nécessaire d'utiliser un fichier NEWS.Debian avec le paquet. Pas de nouvelles, bonnes nouvelles !

6.4. Best practices around security

A set of suggestions and links to other reference documents around security aspects for packaging can be found at the Developer's Best Practices for OS Security chapter inside the Securing Debian Manual.

6.5. Meilleures pratiques pour les scripts du responsable

Les scripts du responsable (« maintainer scripts ») sont les fichiers debian/postinst, debian/preinst, debian/prerm et debian/postrm. Ces scripts peuvent prendre en charge les phases d'installation ou de désinstallation non automatiquement gérées par la création ou la suppression de fichiers ou de répertoires. Les instructions qui suivent complètent celles de la Charte Debian.

Les scripts du responsable doivent être idempotents. Cela signifie que vous devez vous assurer que rien de grave ne se produit si un script est lancé deux fois au lieu d'une.

L'entrée et la sortie standard peuvent être redirigées (par exemple dans des tuyaux, ou « pipes ») pour des besoins de journalisation. Il est donc recommandé qu'ils ne soient pas dépendants d'un terminal.

Toute interaction avec l'utilisateur doit être limitée au maximum. Lorsqu'elle est nécessaire, vous devriez utiliser le paquet debconf comme interface. Veuillez noter que l'interaction doit impérativement se faire à l'étape configure du script postinst.

Les scripts du responsable doivent rester aussi simples que possible et utiliser de préférence des scripts shell POSIX stricts. Veuillez noter que si vous avez besoin de spécificités de Bash, vous devez utiliser une ligne « shebang » pour Bash. Les scripts POSIX ou Bash sont encouragés par rapport aux scripts Perl, car debhelper peut alors y ajouter des fonctions.

Si vous modifiez les scripts du responsable, veillez à vérifier la suppression du paquet, la double installation et la purge. Vérifiez qu'un paquet purgé est entièrement éliminé, c'est-à-dire que les fichiers créés, directement ou indirectement dans les scripts du responsable, sont tous supprimés.

Pour vérifier l'existence d'une commande, vous devriez utiliser quelque chose comme :

if command -v install-docs > /dev/null; then ...

Vous pouvez utiliser cette fonction pour rechercher dans $PATH une commande donnée, passée en paramètre. Elle renvoie « true » (zéro) si la commande est trouvée et « false » dans le cas contraire. Il s'agit de la méthode la plus portable, car command -v est une commande interne pour plusieurs interpréteurs de commande et elle est définie dans POSIX.

L'utilisation de which est une alternative acceptable dans la mesure où elle est fournie par le paquet debianutils qui est requis.

6.6. Gestion de la configuration avec debconf

debconf est un système de gestion de configuration utilisable par les divers scripts des paquets (postinst notamment) pour interagir avec l'utilisateur sur des choix à opérer pour la configuration du paquet. Les interactions directes avec l'utilisateur doivent maintenant être évitées en faveur de debconf, notamment pour permettre des installations non interactives dans le futur.

debconf est un outil très pratique, mais souvent mal utilisé. De nombreuses erreurs classiques sont mentionnées dans la page de manuel debconf-devel 7. Il est indispensable de lire cette page de manuel avant de décider d'utiliser debconf. Quelques bonnes pratiques sont également indiquées dans le présent document.

Les conseils qui suivent comportent des indications sur le style d'écriture et la typographie, des considérations générales sur l'utilisation de debconf ainsi que des recommandations plus spécifiques relatives à certaines parties de la distribution (le système d'installation notamment).

6.6.1. Proscrire les abus de debconf

Depuis que debconf est apparu dans Debian, il a été tellement utilisé que de nombreuses critiques ont été émises à l'encontre de la distribution Debian pour abus d'utilisation de debconf, avec la nécessité de répondre à un nombre très important de questions avant d'avoir un quelconque outil installé.

Les notes d'utilisation doivent être réservées à leur emplacement naturel : le fichier NEWS.Debian ou README.Debian. N'utilisez les notes que pour des points importants qui peuvent directement concerner l'utilisabilité du paquet. Les notes interrompent l'installation tant qu'elles ne sont pas confirmées et elles peuvent conduire à des envois de courriers électroniques aux utilisateurs.

Choisissez soigneusement les priorités des questions posées dans les scripts du responsable. Veuillez consulter la page de manuel debconf-devel 7 pour plus de détails sur les priorités. La plupart des questions devraient utiliser les priorités intermédiaire (medium) ou basse (low).

6.6.2. Recommandations générales pour les auteurs et les traducteurs

6.6.2.1. Utilisation d'un anglais correct

La plupart des responsables de paquet Debian ne sont pas anglophones. Il n'est donc pas nécessairement facile pour eux d'écrire des écrans correctement.

Pensez à utiliser (voire abuser de) la liste debian-l10n-english@lists.debian.org. Faites relire vos écrans.

Des écrans mal écrits fournissent une image négative de votre paquet, de votre travail ou même de Debian en général.

Évitez autant que possible le jargon technique. Si certains termes vous sont familiers, ils peuvent être incompréhensibles à d'autres. Si vous ne pouvez les éviter, tentez de les expliquer (avec la description étendue). Dans ce cas, tentez de faire la part des choses entre simplicité et verbosité.

6.6.2.2. Courtoisie avec les traducteurs

Les écrans debconf peuvent être traduits. Les paquets debconf et po-debconf fournissent un cadre simple permettant la traduction des écrans par des équipes de traduction ou des traducteurs isolés.

Utilisez des écrans permettant l'utilisation de gettext. Installez le paquet po-debconf sur votre machine de développement et lisez sa documentation (man po-debconf est un bon début).

Évitez de changer les écrans trop souvent. Les modifications de texte ont une incidence sur le travail des traducteurs dont les traductions vont devenir approximatives (« fuzzy »). Une chaîne de caractères devient approximative quand la version originale a été modifiée depuis la traduction, demandant ainsi une mise à jour par un traducteur pour être utilisable. Si les modifications sont mineures, la traduction originale est conservée dans le fichier PO, mais marquée fuzzy.

Si vous prévoyez de modifier les écrans d'origine, veuillez utiliser le système de notification podebconf-report-po, fourni avec le paquet po-debconf, pour contacter les traducteurs. La plupart des traducteurs sont réactifs, et inclure leur mise à jour en même temps que les modifications des écrans d'origine vous évitera des envois ultérieurs pour mettre à jour des traductions. Si vous utilisez des écrans se servant de gettext, le nom et l'adresse électronique des traducteurs sont mentionnés dans les en-têtes des fichiers PO et seront utilisés par podebconf-report-po.

Une façon recommandée de se servir de cet utilitaire est :

cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"

Cette commande synchronisera d'abord les fichiers PO et POT de debian/po avec les fichiers d'écrans listés en debian/po/POTFILES.in. Ensuite, elle déclenchera un appel à de nouvelles traductions sur la liste de diffusion debian-i18n@lists.debian.org. Enfin, elle déclenchera un appel à mise à jour de traduction aux équipes de traductions (indiquées dans le champ Language-Team de chaque fichier PO) ainsi qu'au dernier traducteur (indiqué en Last-translator).

La mention d'une date limite aux traducteurs est toujours appréciée, pour leur permettre d'organiser leur travail. Veuillez ne pas oublier que certaines équipes ont formalisé leur processus de traduction et révision de telle sorte qu'un délai inférieur à dix jours n'est pas considéré comme raisonnable. Un délai plus court met trop de pression sur les équipes de traduction et ne devrait être réservé qu'aux modifications mineures.

Dans le doute, vous pouvez également contacter l'équipe de traduction d'une langue donnée (debian-l10n-xxxxx@lists.debian.org) ou la liste de diffusion debian-i18n@lists.debian.org.

6.6.2.3. Correction (« unfuzzy ») des traductions pour des erreurs typographiques ou de frappe

Lorsque le texte d'un écran debconf est corrigé et que vous avez la certitude que la modification n'affecte pas les traductions, pensez aux traducteurs et rendez leur traductions à nouveau complètes (« unfuzzy »).

Si cela n'est pas fait, l'ensemble de l'écran debconf ne sera plus traduit tant qu'un traducteur n'aura pas envoyé de mise à jour.

Pour rendre les traductions à nouveau complètes (« unfuzzy »), vous pouvez utiliser msguntypot (du paquet po4a).

1. Recréez les fichiers POT et PO.

   debconf-updatepo
   

2. Faites une copie du fichier POT.

   cp templates.pot templates.pot.orig
   

3. Faites une copie de tous les fichiers PO.

   mkdir po_fridge; cp *.po po_fridge
   

4. Modifier les fichiers d'écrans debconf (templates) pour corriger les fautes de frappe.

5. Recréez les fichiers POT et PO (de nouveau).

   debconf-updatepo
   

   À ce moment-là, la correction a marqué certaines chaînes approximatives, et ce changement est malheureusement la seule modification entre les fichiers PO du répertoire et ceux de po_orig. Voici comment corriger cela.

6. Abandonnez les traductions approximatives, récupérer celles du répertoire originel.

   cp po_fridge/*.po .
   

7. Fusionnez manuellement les fichiers PO avec le nouveau fichier POT, en prenant en compte le fait que les étiquettes « fuzzy » sont inutiles.

   msguntypot -o templates.pot.orig -n templates.pot *.po
   

8. Nettoyage.

   rm -rf templates.pot.orig po_fridge
   

6.6.2.4. Proscrire toute supposition sur les interfaces utilisateurs

Les textes des écrans ne devraient pas faire référence aux éléments disponibles sur certaines interfaces de debconf. Des phrases telles que « If you answer Yes » ne signifient rien avec les interfaces graphiques où des boutons radio sont utilisés pour les questions booléennes.

Les écrans de type string ne devraient pas faire référence aux valeurs par défaut dans leur description. Cela est tout d'abord redondant avec les valeurs visibles par les utilisateurs. Mais également, les valeurs présentées par défaut peuvent être différentes du choix du responsable (par exemple, lorsque la base de données de debconf a été pré-renseignée).

De manière plus générale, évitez de faire référence à des actions particulières des utilisateurs et donnez simplement des faits.

6.6.2.5. Proscrire l'utilisation de la première personne

Vous devriez éviter l'utilisation de la première personne (« I will do this... » ou « We recommend... »). L'ordinateur n'est pas une personne et les écrans de debconf ne parlent pas au nom des développeurs de Debian. Vous devriez utiliser des constructions neutres. Pour les personnes familières de la publication scientifique, il suffit en général d'adopter le style d'écriture qui y est utilisé. Tentez cependant d'utiliser la forme active si possible. Par exemple : « Enable this if... » au lieu de « This can be enabled if... ».

6.6.2.6. Neutralité en genre

Pour se conformer à notre engagement de diversité et équité, veuillez utiliser des constructions de genre neutre dans votre écriture. Cela signifie éviter les pronoms tels que il ou elle lors d’une référence à un rôle (tel que « responsable ») dont le genre est inconnu. À la place, vous devriez utiliser une forme plurielle (They singulier).

6.6.3. Définition des champs de modèles (« templates »).

Les informations présentées dans cette partie proviennent pour l'essentiel de la page de manuel debconf-devel 7.

6.6.3.1. Type

6.6.3.1.1. string

offre un champ de saisie où l'utilisateur peut entrer n'importe quelle chaîne de caractères.

6.6.3.1.2. password

demande un mot de passe. Ce champ est à utiliser avec précaution, car le mot de passe saisi sera conservé dans la base de données de debconf. Il est conseillé d'effacer cette valeur de la base de données dès que possible.

6.6.3.1.3. boolean

offre un choix du type « vrai » ou « faux ». N'oubliez pas, c'est bien un choix « vrai » ou « faux », pas « oui » ou « non »...

6.6.3.1.4. select

offre le choix entre différentes valeurs. Les choix doivent être indiqués dans un champ appelé « Choices ». Les différentes valeurs doivent être séparées par des virgules et des espaces, comme ceci : « Choices: yes, no, maybe ».

Si les choix sont traduisibles, le champ « Choices » peut être marqué traduisible en utilisant « __Choices ». Les deux tirets bas permettent à chaque choix de devenir une chaîne différente proposée à la traduction.

Le système po-debconf offre également la possibilité intéressante de ne marquer que certains choix traduisibles. Par exemple :

Template: foo/bar
Type: Select
#flag:translate:3
__Choices: PAL, SECAM, Other
_Description: TV standard:
 Please choose the TV standard used in your country.

Dans cet exemple, seule la chaîne « Other » est traduisible, alors que les autres sont des acronymes qui ne devraient pas êtres traduits. Seul « Other » sera inclus dans les fichiers PO et POT.

Le système d'indicateur (« flag ») d'écrans debconf permet de faire de telles choses. La page de manuel po-debconf 7 documente toutes ces possibilités.

6.6.3.1.5. multiselect

similaire au type select, mais permet de choisir plusieurs (ou aucune) valeurs parmi la liste de choix.

6.6.3.1.6. note

plus qu'une vraie question, ce type indique une note affichée aux utilisateurs. Elle doit être réservée à des informations importantes que l'utilisateur doit absolument voir, car debconf fera tout pour s'assurer qu'elle soit visible, en interrompant l'installation jusqu'à ce qu'une touche soit appuyée, voire en envoyant la note par courrier électronique dans certains cas.

6.6.3.1.7. text

ce type est maintenant obsolète : il ne faut pas l'utiliser.

6.6.3.1.8. error

ce type permet de gérer des messages d'erreur. Il est analogue au type note. Les interfaces utilisateur peuvent le présenter différemment (par exemple l'interface cdebconf dessine un écran à fond rouge au lieu de l'écran bleu habituel).

Il est recommandé d'utiliser ce type pour tout message qui requiert l'attention de l'utilisateur pour procéder à une correction, quelle qu'elle soit.

6.6.3.2. Description : descriptions courte et étendue

Les descriptions de modèle comportent deux parties : la partie courte et la partie étendue. La partie courte est celle qui est placée sur la ligne Description du modèle.

La partie courte doit rester courte (une cinquantaine de caractères) afin d'être gérée par la majorité des interfaces de debconf. La garder courte facilite également le travail des traducteurs, car les traductions sont souvent plus longues que les textes originaux.

La description courte doit être autonome. Certaines interfaces ne montrent pas la description longue par défaut ou ne la montrent que si l'utilisateur le demande explicitement. Il est ainsi déconseillé d'utiliser des phrases comme « What do you want to do? » (« Que voulez vous faire ? »)

La description courte ne doit pas nécessairement être une phrase entière. C'est une façon de la garder courte et efficace.

La partie longue ne doit pas répéter la partie courte. Si vous ne trouvez pas de partie longue appropriée, réfléchissez un peu plus. Demandez dans debian-devel. Demandez de l'aide. Prenez un cours d'écriture ! La description longue est importante. Si, malgré tout cela, vous ne trouvez rien d'intéressant à ajouter, laissez-la vide.

La partie longue doit utiliser des phrases complètes. Les paragraphes doivent rester courts pour améliorer la lisibilité. Ne placez pas deux idées différentes dans le même paragraphe, mais séparez-les en deux paragraphes.

Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ne pas lire les écrans trop longs. Une vingtaine de lignes est une limite que vous ne devriez pas dépasser car, avec l'interface dialog standard, les utilisateurs devront monter et descendre avec des ascenseurs, ce que la plupart des utilisateurs ne font simplement pas.

La partie longue de la description ne devrait jamais comporter de question.

Les parties qui suivent donnent des recommandations spécifiques pour certains types de modèles (string, boolean, etc.).

6.6.3.3. Choices

Ce champ doit être utilisé pour les types select et multiselect. Il contient les choix proposés aux utilisateurs. Ces choix doivent être séparés par des virgules.

6.6.3.4. Default

Ce champ optionnel contient la réponse par défaut pour les modèles string, select et multiselect. Dans ce dernier cas, il peut comporter une liste de choix multiples, séparés par des virgules.

6.6.4. Guide de style spécifique à certains champs de modèle

6.6.4.1. Champ Type

Pas d'indication particulière si ce n'est choisir le type adapté en se référant à la section précédente.

6.6.4.2. Champ Description

Vous trouverez ici des instructions particulières pour l'écriture du champ Description (parties courte et longue) selon le type de modèle.

6.6.4.2.1. Modèles string et password

• La description courte est une invite et pas un titre. Il faut éviter la forme interrogative (« IP Address? ») au profit d'une invite ouverte (« Adresse IP : »). L'utilisation d'un deux-points final est recommandée.

• La partie longue complète la partie courte. Il est conseillé d'y expliquer ce qui est demandé, plutôt que de répéter la même demande. Utilisez des phrases complètes. Un style d'écriture abrégé est déconseillé.

6.6.4.2.2. Modèles boolean

• La partie courte devrait utiliser la forme interrogative, rester courte et se terminer par un point d'interrogation. Un style abrégé est toléré et même encouragé si la question est complexe (les traductions sont souvent plus longues que les versions originales).

• Il est important de ne pas faire référence aux spécificités de certaines interfaces. Une erreur classique est d'utiliser une construction comme « If you answer Yes... » (« Si vous répondez Oui... »).

6.6.4.2.3. Modèles select et multiselect

• La description courte est une invite et pas un titre. N'utilisez pas de constructions comme « Please choose... » (« Veuillez choisir... »). Les utilisateurs sont suffisamment intelligents pour comprendre qu'il est nécessaire de choisir quelque chose.

• La description longue complète la partie courte. Elle peut faire référence aux choix disponibles. Elle peut aussi indiquer que l'utilisateur peut sélectionner plus d'un choix parmi ceux disponibles, pour les modèles multiselect (bien que l'interface rende en général cela tout à fait clair).

6.6.4.2.4. Modèles note

• La description courte doit être considérée comme un titre.

• La partie longue est ce qui sera affiché comme description plus détaillée de la note. Il est déconseillé d'y utiliser un style abrégé.

• N'abusez pas de ``debconf``. Les notes sont un des abus les plus fréquents de debconf. Comme indiqué dans la page de manuel de debconf, elles devraient être réservées pour avertir les utilisateurs de problèmes très importants. Les fichiers NEWS.Debian ou README.Debian sont les endroits appropriés pour la majorité des notes. Si, à la lecture de ces conseils, vous envisagez de convertir vos modèles de type note en entrée dans NEWS.Debian ou README.Debian, pensez à conserver d'éventuelles traductions existantes.

6.6.4.3. Champ Choices

Si les choix changent souvent, il est suggéré d'utiliser l'astuce « __Choices ». Avec ce format, chaque choix sera une chaîne différente proposée à la traduction, ce qui facilite grandement le travail des traducteurs.

6.6.4.4. Champ Default

Si la valeur par défaut pour un modèle choisi est susceptible de dépendre de la langue de l’utilisateur (par exemple si le choix concerne la langue), pensez à utiliser l’astuce _Default, documentée dans la page de manuel po-debconf 7.

Ce champ spécial permet aux traducteurs de mettre le choix le plus adapté à leur langue, qui deviendra le choix par défaut quand cette langue est utilisée, alors que le choix par défaut que vous avez mentionné sera utilisé en anglais.

N'utilisez pas de champ Default vide. Si vous ne souhaitez pas avoir de valeur par défaut, n'utilisez pas du tout ce champ.

Quand vous utilisez po-debconf, (et vous devriez, voir Courtoisie avec les traducteurs), veuillez rendre ce champ traduisible si vous pensez qu'il peut l'être.

Exemple, pris dans le paquet geneweb :

Template: geneweb/lang
Type: select
__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
# This is the default choice. Translators may put their own language here
# instead of the default.
# WARNING : you MUST use the ENGLISH NAME of your language
# For instance, the French translator will need to put French (fr) here.
_Default: English[ translators, please see comment in PO files]
_Description: Geneweb default language:

Veuillez noter l'utilisation de crochets pour autoriser des commentaires internes dans les champs de debconf. Notez également l'utilisation de commentaires qui apparaîtront dans les fichiers de travail des traducteurs.

Les commentaires sont très utiles, car l'astuce « _Default » est parfois déroutante pour les traducteurs qui pourraient y mettre leur propre choix.

6.7. Internationalisation

Cette section fournit des informations générales à destination des développeurs pour simplifier la vie des traducteurs. Vous trouverez plus d'informations à destination des traducteurs et développeurs intéressés par l'internationalisation dans la documentation sur l'internationalisation et la localisation dans Debian.

6.7.1. Gestion des traductions debconf

Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur de nombreux paquets et doivent collaborer avec de nombreux responsables. De plus, ils n'ont généralement pas la langue anglaise comme langue maternelle et vous devez donc faire preuve d'une patience particulière avec eux.

L'objectif de debconf est de rendre la configuration des paquets plus facile pour les responsables de paquets et pour les utilisateurs. Initialement, la traduction des écrans de debconf était gérée avec debconf-mergetemplate. Cependant, cette technique est désormais obsolète et la meilleure façon d'internationaliser debconf est d'utiliser le paquet po-debconf. Cette méthode simplifie le travail des traducteurs et des responsables et des scripts de transition sont fournis.

Avec po-debconf, les traductions sont gérées dans des fichiers .po (hérités des techniques de traduction utilisées avec gettext). Des fichiers modèles contiennent les messages d'origine et les champs à traduire y sont marqués spécifiquement. Lorsque le contenu d'un champ traduisible est modifié, l'emploi de la commande debconf-updatepo permet d'indiquer que la traduction a besoin d'une mise à jour par les traducteurs. Ensuite, au moment de la construction du paquet, le programme dh_installdebconf s'occupe des opérations nécessaires pour ajouter le modèle avec les traductions à jour dans les paquets binaires. Vous pouvez consulter la page de manuel de po-debconf 7 pour plus d'informations.

6.7.2. Documentation internationalisée

L'internationalisation de la documentation est primordiale pour les utilisateurs, mais représente un travail très important. Même s'il n'est pas possible de supprimer tout le travail nécessaire, il est possible de faciliter la tâche des traducteurs.

Si vous maintenez une documentation de quelque taille que ce soit, il sera plus pratique pour les traducteurs d'avoir accès au système de suivi des versions source. Cela leur permet de voir les différences entre deux versions de la documentation et, par conséquent, de mieux voir où les traductions doivent être modifiées. Il est recommandé que la documentation traduite contienne l'indication du système de suivi des versions source qui est utilisé. Un système pratique est fourni par doc-check du paquet debian-installer, qui permet un survol de l'état de la traduction pour toute langue, par l'utilisation de commentaires structurés dans la version du fichier à traduire et, pour le fichier traduit, la version du fichier sur laquelle est basée la traduction. Il est possible d'adapter ce système dans votre propre dépôt de gestion de versions.

Si vous maintenez de la documentation en format XML ou SGML, il est conseillé d'isoler l'information indépendante de la langue et de la définir sous forme d'entités dans un fichier à part qui sera inclus par toutes les traductions. Cela rend par exemple plus simple la maintenance d'URL dans de nombreux fichiers.

Certains outils (par exemple po4a, poxml, ou translate-toolkit) sont spécialisés dans l'extraction des composants traduisibles depuis différents formats. Ils fabriquent des fichiers PO (un format plutôt habituel pour les traducteurs), qui permettent de voir les traductions à mettre à jour quand le document a été modifié.

6.8. Situations courantes de gestion de paquets

6.8.1. Paquets utilisant autoconf ou automake

Pouvoir disposer de fichiers config.sub et config.guess à jour est un point critique pour les porteurs, particulièrement pour les architectures assez volatiles. De très bonnes pratiques applicables à tout paquet qui utilise autoconf ou automake ont été résumées dans /usr/share/doc/autotools-dev/README.Debian.gz du paquet autotools-dev. Il est fortement recommandé de lire ce fichier et d'en suivre les recommandations.

6.8.2. Bibliothèques

Les paquets fournissant des bibliothèques sont plus difficiles à maintenir pour plusieurs raisons. La Charte impose de nombreuses contraintes pour en faciliter la maintenance et garantir que les mises à niveau sont aussi simples que possible quand une nouvelle version amont est disponible. Des erreurs dans une bibliothèque sont susceptibles de rendre inutilisables de très nombreux paquets.

Les bonnes pratiques pour la maintenance de paquets fournissant des bibliothèques ont été rassemblées dans le guide de gestion des paquets de bibliothèque.

6.8.3. Documentation

Veuillez vous assurer que vous suivez la Charte de documentation.

Si votre paquet contient de la documentation construite à partir de fichiers XML ou SGML, il est recommandé de ne pas fournir ces fichiers source dans les paquets binaires. Les utilisateurs qui souhaiteraient disposer des sources de la documentation peuvent alors récupérer le paquet source.

La Charte indique que la documentation devrait être fournie en format HTML. Il est recommandé de la fournir également dans les formats PDF et texte si cela est pratique et si un affichage de qualité raisonnable est possible. Cependant, il est le plus souvent inapproprié de fournir en format texte simple des versions de documentations dont le format source est HTML.

Les manuels les plus importants qui sont fournis devraient être enregistrés avec doc-base lors de leur installation. Veuillez consulter la documentation du paquet doc-base pour plus d'informations.

La Charte Debian (section 12.1) indique que des pages de manuel devraient être fournies avec chaque programme, utilitaire et fonction, et suggère d'en fournir pour les autres éléments comme les fichiers de configuration. Si le travail que vous empaquetez ne fournit pas de telles pages de manuel, veuillez envisager de les écrire pour les ajouter à votre paquet et les proposer en amont.

Les pages de manuel n'ont pas besoin d'être écrites directement au format troff. Les formats source populaires Docbook, POD et reST peuvent être convertis en utilisant respectivement xsltproc, pod2man et rst2man. De moins grande ampleur, le programme help2man peut aussi être utilisé pour écrire une ébauche.

6.8.4. Catégories particulières de paquets

Plusieurs catégories particulières de paquets utilisent des chartes spécifiques avec leurs règles et leurs pratiques d'empaquetage.

• Les paquets liés à Perl utilisent une charte Perl. Des exemples de tels paquets qui appliquent cette charte spécifique sont libdbd-pg-perl (module Perl binaire) ou libmldbm-perl (module Perl indépendant de l'architecture).

• Les paquets liés à Python utilisent une charte Python. Veuillez consulter le fichier /usr/share/doc/python/python-policy.txt.gz du paquet python pour plus d'informations.

• Les paquets liés à Emacs utilisent une charte Emacs.

• Les paquets liés à Java utilisent une charte Java.

• Les paquets liés à OCaml utilisent leur propre charte, que l'on peut trouver dans le fichier /usr/share/doc/ocaml/ocaml_packaging_policy.gz du paquet ocaml. Un bon exemple est fourni par le paquet source camlzip.

• Les paquets fournissant des DTD XML ou SGML devraient suivre les recommandations données dans le paquet sgml-base-doc.

• Les paquets Lisp doivent s'enregistrer avec common-lisp-controller, pour lequel plus d'information est disponible dans /usr/share/doc/common-lisp-controller/README.packaging.

• Rust packaging is described in the Debian Rust Team Book;.

6.8.5. Données indépendantes de l'architecture

Il est fréquent qu'un grand nombre de données indépendantes de l'architecture soient fournies avec un programme. Cela peut être par exemple des fichiers audio, un ensemble d'icônes, des motifs de papier-peint ou d'autres fichiers graphiques. Si la taille de ces données est négligeable par rapport à la taille du reste du paquet, il est probablement préférable de laisser l'ensemble dans un seul paquet.

Cependant, si cette taille est importante, vous devriez réfléchir à les fournir dans un paquet séparé, indépendant de l'architecture (_all.deb). Cela permet ainsi d'éviter la duplication des mêmes données dans de nombreux paquets binaires, un par architecture. Bien que cela ajoute des entrées dans les fichiers Packages, cela permet d'économiser une place importante sur les miroirs de Debian. La séparation des données indépendantes de l'architecture réduit également le temps de traitement de lintian (voir Contrôle de paquets (« lint »)) lorsqu'il est utilisé sur l'archive Debian en entier.

6.8.6. Besoin de paramètres régionaux spécifiques lors de la construction

Si des paramètres régionaux (« locale ») sont nécessaires pour la construction d'un paquet, vous pouvez créer un fichier temporaire avec l'astuce suivante.

Si la variable LOCPATH est placée sur l'équivalent de /usr/lib/locale et LC_ALL sur le nom des paramètres régionaux à créer, vous devriez pouvoir obtenir le résultat escompté sans avoir les privilèges du superutilisateur. La séquence ressemblera alors à :

LOCALE_PATH=debian/tmpdir/usr/lib/locale
LOCALE_NAME=en_IN
LOCALE_CHARSET=UTF-8

mkdir -p $LOCALE_PATH
localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET

# Using the locale
LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date

6.8.7. Paquets de transition conformes à deborphan

Le programme deborphan permet aux utilisateurs d'identifier les paquets pouvant être supprimés sans crainte du système, c'est-à-dire ceux dont aucun paquet ne dépend. Par défaut, l'utilitaire n'effectue sa recherche que parmi les paquets de bibliothèque et les sections libs et oldlibs, afin de traquer les bibliothèques inutilisées. Cependant, avec le paramètre approprié, il peut rechercher d'autres paquets inutiles.

Par exemple, avec l'option --guess-dummy, deborphan essaye de trouver tous les paquets de transition qu'il était nécessaire de mettre à niveau, mais qui peuvent maintenant être supprimés. Pour ce faire, deborphan recherche les chaînes dummy ou transitional dans leur description courte, bien que ce serait mieux de rechercher les deux, dans la mesure où il y a des paquets dummy ou transitional qui ont d'autres finalités.

Ainsi, lorsque vous avez besoin de créer un tel paquet, veuillez prendre soin d'ajouter transitional dummy package à sa description courte pour rendre ce statut explicite. Il est facile de trouver des exemples avec les commandes apt-cache search .|grep dummy ou apt-cache search .|grep transitional.

De même, vous devriez configurer sa section en oldlibs et sa priorité en optional afin de faciliter le travail de deborphan.

6.8.8. Meilleures pratiques pour les fichiers .orig.tar.{gz,bz2,xz}

Il existe deux sortes différentes d'archives source d'origine. Les sources originelles (« pristine ») et les sources reconstruites (« repackaged »).

6.8.8.1. Source originelle (« pristine »)

La caractéristique définissant une archive source originelle est que le fichier .orig.tar.{gz,bz2,xz} est strictement identique à l'archive fournie par l'auteur amont. [1]. Cela permet d'utiliser des sommes de contrôle pour vérifier que toutes les modifications effectuées entre la version Debian et la version amont sont contenues dans le fichier de différences Debian. De même, si la taille des sources d'origine est importante, les auteurs amont et tous ceux qui disposent de l'archive amont d'origine peuvent économiser du temps de téléchargement s'ils souhaitent contrôler le paquet en détail.

Il n'existe pas de convention universellement acceptée pour la structure de répertoires que devraient adopter les auteurs amont dans les archives qu'ils publient, mais dpkg-source peut de toute manière traiter la plupart des archives amont comme des sources originelles. La stratégie de cette commande est la suivante :

1. elle extrait l'archive dans un répertoire temporaire :

   zcat path/to/packagename_upstream-version.orig.tar.gz | tar xf -
   

2. si, après cela, le répertoire temporaire ne contient qu'un seul répertoire sans fichiers, dpkg-source renomme ce répertoire en nomdupaquet-version-amont(.orig). Le nom du répertoire parent de l'archive tar n'a pas d'importance et est oublié ;

3. si ce n'est pas le cas, l'archive amont a été créée sans répertoire parent (honte à l'auteur amont !). Dans ce cas, dpkg-source renomme le répertoire temporaire lui-même en nomdupaquet-version-amont(.orig).

6.8.8.2. Source amont reconstruite

Vous devriez envoyer les paquets avec une archive source inchangée, dans la mesure du possible. Il existe cependant plusieurs raisons qui peuvent rendre cela impossible. C'est notamment le cas si les auteurs amont ne distribuent pas d'archive tar compressée du tout ou si l'archive amont contient des parties non conformes aux principes du logiciel libre selon Debian, qui doivent être supprimées avant l'envoi.

Dans ces cas, les responsables doivent construire eux-mêmes une archive .orig.tar.{gz,bz2,xz}. Cette archive sera appelée une archive amont reconstruite. Il est important de noter qu'elle reste différente d'un paquet natif. Une archive reconstruite est toujours fournie avec les changements propres à Debian dans un fichier .diff.gz ou .debian.tar.{gz,bz2,xz} séparé et son numéro de version est toujours composé de upstream-version et debian-version.

Il peut exister des cas où il est souhaitable de reconstruire une archive source alors que les auteurs amont fournissent bien une archive .tar.{gz,bz2,xz} qui pourrait être utilisée directement. Le plus évident est la recherche d'un gain de place significatif par recompression ou par suppression de scories inutiles de l'archive source d'origine. Il est important que le responsable exerce avec discernement son propre jugement et soit prêt à le justifier si l'archive source est reconstruite alors qu'elle aurait pu être fournie telle quelle.

Un fichier .orig.tar.{gz,bz2,xz} reconstruit :

1. should be documented in the resulting source package. Detailed information on how the repackaged source was obtained, and on how this can be reproduced should be provided in debian/copyright, ideally in a way that can be done automatically with uscan. If that really doesn't work, at least provide a get-orig-source target in your debian/rules file that repeats the process, even though that was actually deprecated in the 4.1.4 version of the Debian policy.

2. ne devrait pas contenir de fichier non distribué par les auteurs amont, ou dont vous avez modifié le contenu ; [2]

3. should, except where impossible for legal reasons, preserve the entire building and portability infrastructure provided by the upstream author. For example, it is not a sufficient reason for omitting a file that it is used only when building on MS-DOS. Similarly, a Makefile provided by upstream should not be omitted even if the first thing your debian/rules does is to overwrite it by running a configure script.

   (Raison : les utilisateurs Debian ont l'habitude, pour compiler des logiciels sur des systèmes non Debian, de prendre les sources depuis les miroirs Debian plutôt que d'essayer de trouver le dépôt officiel amont) ;

4. may use packagename-upstream-version+dfsg (or any other suffix which is added to the tarball name) as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones.

5. devrait être compressé avec xz (ou gzip ou bzip) et utiliser le taux de compression maximal.

6.8.8.3. Modification de fichier binaire

Il est parfois nécessaire de modifier les fichiers binaires contenus dans l'archive d'origine, ou d'ajouter des fichiers binaires. C'est tout à fait possible avec les paquets au format « 3.0 (quilt) ». Consultez la page de manuel dpkg-source1 pour plus de détails. Avec le plus ancien format « 1.0 », .diff.gz ne peut pas contenir de fichiers binaires, ce qui oblige à utiliser uuencode (ou une fonction similaire) pour les stocker, puis à les reconstruire lors de la compilation dans debian/rules (et les remettre à leur place).

6.8.9. Meilleures pratiques pour les paquets de débogage

Un paquet de débogage est un paquet qui contient des informations supplémentaires que gdb peut utiliser. Puisque les binaires de Debian sont élagués par défaut, les informations de débogage, comme les noms de fonction et les numéros de ligne, ne sont pas disponibles lors de l'utilisation de gdb sur les paquets binaires. Les paquets de débogage permettent aux utilisateurs, qui ont besoin de ces informations de débogage complémentaires, d'ajouter ces informations supplémentaires et d’éviter d’augmenter la taille d'un système normal.

Les paquets de débogage contiennent des symboles de débogage distincts que gdb peut trouver et charger à la volée lors du débogage d'un programme ou d'une bibliothèque. Par convention dans Debian, ces symboles sont conservés dans /usr/lib/debug/chemin, où chemin est l'arborescence vers l'exécutable ou la bibliothèque. Par exemple, les symboles de débogage pour /usr/bin/truc sont dans /usr/lib/debug/usr/bin/truc, et les symboles de débogage pour /usr/lib/libtruc.so.1 sont dans /usr/lib/debug/usr/lib/libtruc.so.1.

6.8.9.1. Paquets de débogage créés automatiquement

Les paquets de symboles de débogage peuvent être créés automatiquement pour n’importe quel paquet binaire contenant des exécutables, et sauf cas pathologiques, il ne devrait plus être nécessaire d’utiliser l’ancienne méthode de création manuelle. Le nom de paquet pour un nom de paquet de symboles de débogage généré automatiquement se termine par -dbgsym.

Les paquets dbgsym ne sont pas installés dans des archives standard, mais dans des archives spéciales. Cela signifie que si vous avez besoin de symboles de débogage pour le débogage, vous devez ajouter ces archives dans votre configuration d’apt et puis installer le paquet dbgsym qui vous intéresse. Veuillez lire https://wiki.debian.org/HowToGetABacktrace pour connaître la manière de faire.

6.8.9.2. Paquets -dbg manuels

Avant l’introduction des paquets automatiques dbgsym, les paquets de débogage devaient être créés manuellement. Le nom de ces paquets se terminent par -dbg. Il est recommandé de migrer de tels anciens paquets vers les nouveaux paquets dbgsym autant que possible. La procédure de conversion est décrite dans https://wiki.debian.org/AutomaticDebugPackages, mais l’idée générale est d’utiliser le commutateur --dbgsym-migration='pkgname-dbg (<< currentversion~)' de la commande dh_strip.

Cependant, parfois il n’est pas possible de convertir vers les nouveaux paquets dbgsym, ou vous rencontrerez les anciens paquets manuels -dbg dans les archives, donc vous devrez les gérer. Il n’est pas recommandé de créer des paquets -dbg pour les nouveaux paquets, sauf si les paquets automatiques ne fonctionnent pas pour une raison quelconque.

Une raison peut être que les paquets de débogage contiennent une construction spéciale de débogage d’une bibliothèque ou autre binaire. Cependant, généralement séparer des informations de débogage des binaires déjà construits est suffisant et économisera de l’espace au moment de la compilation.

C’est le cas, par exemple, pour les symboles de débogage des extensions de Python. Pour l’instant, la façon correcte d’empaqueter les symboles de débogage des extensions de Python est d’utiliser les paquets -dbg comme décrit dans https://wiki.debian.org/Python/DbgBuilds.

Pour créer des paquets -dbg, le responsable doit les stipuler explicitement dans debian/control.

Les symboles de débogage peuvent être extraits d'un fichier objet à l'aide de objcopy --only-keep-debug. Ensuite les informations de débogage peuvent être supprimées du fichier objet et objcopy --add-gnu-debuglink peut être utilisé pour préciser le chemin vers le fichier contenant les symboles de débogage. objcopy 1 explique en détail le fonctionnement.

Remarquez que le paquet de débogage devrait dépendre du paquet dont il fournit les symboles de débogage, et que cette dépendance devrait être spécifique à la version. Par exemple

Depends: libfoo (= ${binary:Version})

La commande dh_strip de debhelper permet de créer les paquets de débogage et prend soin d'utiliser objcopy pour séparer les symboles de débogage à votre place. Si le paquet utilise debhelper/9.20151219, ou une version plus récente, inutile de faire quelque chose. debhelper créera les paquets de débogage (sous forme paquet-dbgsym) pour vous sans modifications supplémentaires dans votre paquet source.

6.8.10. Meilleures pratiques pour les métapaquets

Un métapaquet est un paquet quasiment vide qui facilite l'installation d'un ensemble de paquets cohérents qui peut évoluer avec le temps. Il atteint cet objectif en dépendant de tous les paquets de l'ensemble. Grâce à la puissance d'apt, le responsable du métapaquet peut configurer les dépendances et le système de l'utilisateur obtiendra automatiquement les paquets supplémentaires. Les paquets devenus inutiles qui avaient été installés automatiquement seront aussi marqués comme candidats à la suppression (et même automatiquement supprimés par aptitude). Par exemple, gnome et linux-image-amd64 sont deux métapaquets (construits par les paquets source meta-gnome2 et linux-latest).

La description longue du métapaquet doit clairement expliquer son objectif, afin d'informer les utilisateurs sur ce qu'ils perdront s'ils suppriment le paquet. Il est recommandé d'être explicite sur les conséquences. C'est tout particulièrement important pour les métapaquets installés lors de l'installation initiale qui n'ont pas été installés explicitement par l'utilisateur. Ils ont tendance à être importants pour garantir les mises à niveau du système et la description devrait essayer de dissuader les utilisateurs de les désinstaller pour éviter d'éventuels dommages.

[1]

Il est impossible d'empêcher les auteurs amont de modifier l'archive qu'ils distribuent sans également incrémenter le numéro de version. Il est donc impossible de garantir qu'une archive originelle est identique à ce que l'auteur amont distribue à un instant donné. Tout ce qu'il est possible de garantir est qu'elle a été identique à ce que les auteurs amont ont distribué à un moment donné. Si une différence apparaît plus tard (par exemple si les auteurs amont découvrent ne pas avoir utilisé la compression maximale dans leur distribution d'origine et la recompresse, c'est tout simplement dommage. Comme il n'existe pas de méthode adaptée pour envoyer un nouveau fichier .orig.tar.{gz,bz2,xz} pour la même version, il est même totalement inutile de traiter cette situation comme un bogue.

[2]

Avec pour exception particulière, si l'omission de fichiers non libres provoque une erreur de compilation du source sans l'aide du diff Debian, il peut être pertinent de modifier les fichiers pour enlever les portions non libres ou d'expliquer la situation dans un fichier README.source à la racine de l'arbre des sources. Veuillez dans ce cas encourager l'auteur amont à rendre les portions non libres faciles à séparer du reste des sources.

7. Au-delà de l'empaquetage

Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de la maintenance de paquets. Ce chapitre contient des informations sur les façons, souvent vraiment importantes, de contribuer à Debian au-delà des simples création et entretien de paquets.

En tant qu'organisation de volontaires, Debian repose sur la liberté de choisir ce sur quoi l'on désire travailler et de choisir la partie la plus importante à laquelle on veut consacrer son temps.

7.1. Signalement de bogues

Nous vous encourageons à signaler des bogues quand vous en trouvez dans les paquets Debian. En fait, les développeurs Debian sont souvent les testeurs de première ligne. Trouver et signaler les bogues dans les paquets d'autres développeurs améliore la qualité de Debian.

Lisez les instructions pour signaler un bogue dans le système de suivi des bogues Debian.

Essayez de signaler un bogue à partir d'un compte utilisateur normal avec lequel vous pouvez recevoir des courriers, pour que les personnes puissent vous joindre si elles ont besoin de plus d'informations à propos du bogue. Ne signalez pas de bogues en tant que root.

Vous pouvez utiliser un outil comme reportbug(1) pour signaler des bogues. Il peut automatiser et, dans l'ensemble, faciliter le processus.

Assurez-vous que le bogue n'a pas déjà été signalé. Chaque paquet dispose d'une liste de bogues facilement accessible à https://bugs.debian.org/nomdupaquet. Des outils comme querybts(1) peuvent également vous fournir ces informations (et reportbug invoquera également normalement querybts avant l'envoi).

Essayez d'envoyer vos bogues au bon endroit. Quand, par exemple, votre bogue concerne un paquet qui écrase des fichiers d'un autre paquet, vérifiez les listes des bogues pour les deux paquets afin d'éviter de créer des rapports de bogue dupliqués.

Vous pouvez également parcourir les bogues d'autres paquets, en les regroupant s'ils sont indiqués plus d'une fois, ou en les marquant avec fixed quand ils ont déjà été corrigés. Notez cependant que si vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous ne devriez pas fermer réellement le bogue (à moins d'avoir obtenu la permission du responsable).

De temps en temps, vous pourriez vouloir vérifier ce qui s'est passé à propos des bogues que vous avez signalés. Saisissez cette occasion pour fermer les bogues que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez signalés, vous avez simplement besoin de vous rendre à la page https://bugs.debian.org/from:votre-adresse-de-courrier.

7.1.1. Signalement d'un grand nombre de bogues en une fois (mass bug filing)

Signaler de nombreux bogues pour le même problème sur un grand nombre de paquets — c'est-à-dire plus de dix — est une pratique déconseillée. Prenez toutes les mesures possibles pour éviter cette situation. Si le problème peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le paquet lintian pour générer une erreur ou un avertissement.

Si vous voulez signaler plus de dix rapports sur le même sujet, il est préférable d'indiquer votre intention sur la liste debian-devel@lists.debian.org et de le mentionner dans le sujet de votre message. Cela donnera à d'autres développeurs la possibilité de vérifier que le problème existe vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent les mêmes rapports de bogue simultanément.

Veuillez utiliser les programmes dd-list et si nécessaire, whodepends (du paquet devscripts) pour générer une liste de tous les paquets concernés et incluez la sortie dans votre courrier à debian-devel@lists.debian.org.

Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez les envoyer à maintonly@bugs.debian.org pour éviter qu'ils soient renvoyés vers les listes de diffusion.

Le programme mass-bug (du paquet devscripts) peut être utilisé pour envoyer des rapports de bogue pour une liste de paquets.

7.1.1.1. Étiquettes d'utilisateur (Usertags)

Vous pouvez utiliser les étiquettes d'utilisateur du BTS lors du signalement de bogues sur un grand nombre de paquets. Les étiquettes d'utilisateur se comportent de la même façon que les étiquettes patch et wishlist à la différence qu'elles sont définies par l'utilisateur et occupent un espace de définition spécifique propre à l'utilisateur. Cela permet à plusieurs groupes de développeurs de marquer Usertags le même bogue de différentes façons sans conflit.

Pour ajouter des étiquettes d'utilisateur lors du signalement de bogues, précisez les pseudo-en-têtes User et Usertags :

To: submit@bugs.debian.org
Subject: title-of-bug

Package: pkgname
[ ... ]
User: email-addr
Usertags: tag-name [ tag-name ... ]

description-of-bug ...

Remarquez que les étiquettes sont séparées par des espaces et ne peuvent contenir de tiret bas. Si vous signalez des bogues au nom d'un groupe ou d'une équipe spécifique, il vaut mieux définir User comme une liste de diffusion appropriée après y avoir décrit votre intention.

Pour voir les bogues marqués par une étiquette d'utilisateur en particulier, rendez-vous sur la page https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=adresse-mail&tag=nom-d-etiquette.

7.2. Effort d'assurance qualité

7.2.1. Travail quotidien

Bien qu'il y ait un groupe de personnes dédié à l'assurance qualité (QA), les devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à cet effort en conservant vos paquets aussi exempts de bogues que possible et aussi corrects que possible selon lintian (voir lintian). Si cela vous paraît impossible, vous devriez alors envisager d'abandonner certains de vos paquets (voir Abandon de paquet). Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles puissent rattraper votre retard dans la correction des bogues (vous pouvez demander de l'aide sur debian-qa@lists.debian.org ou debian-devel@lists.debian.org). En même temps, vous pouvez rechercher des co-responsables (voir Maintenance collective).

7.2.2. Chasses aux bogues

De temps en temps, le groupe d'assurance qualité organise des chasses aux bogues (Bug Squashing Party) pour essayer de résoudre autant de problèmes que possible. Elles sont annoncées sur debian-devel-announce@lists.debian.org en précisant quel domaine sera visé pendant la chasse : habituellement, il s'agit des bogues empêchant l'intégration du paquet dans la distribution (bogues de gravité Release Critical), mais il peut être décidé d'aider à finir une transition majeure (comme une nouvelle version de Perl qui demande la recompilation de tous les modules binaires).

Les règles pour les mises à jour indépendantes (NMU) sont différentes au cours de la chasse parce que l'annonce de la chasse est considérée comme une annonce préalable pour les NMU. Si vous avez des paquets qui peuvent être affectés par la chasse (parce qu'ils ont des bogues critiques par exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous ne voulez pas de NMU, si vous n'êtes intéressé que par un correctif, ou si vous voulez gérer vous-même le bogue, veuillez l'expliquer dans le BTS.

Les personnes qui participent à la chasse ont des règles spécifiques pour les NMU, elles peuvent en faire une sans avertissement préalable si elles envoient leur paquet avec un délai d'au moins trois jours dans DELAYED/3-day. Toutes les autres règles de NMU s'appliquent comme d'habitude ; le correctif de la NMU devrait être envoyé dans le BTS (pour l'un des bogues ouverts corrigé par la NMU ou pour un nouveau bogue marqué corrigé). Les participants devraient également respecter tout souhait du responsable s'il en a exprimé.

Si vous ne vous sentez pas à l'aise avec une NMU, envoyez simplement un correctif au BTS. C'est de loin préférable à une NMU défectueuse.

7.3. Contact avec d'autres responsables

Pendant vos activités dans Debian, vous contacterez d'autres responsables pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez simplement rappeler à quelqu'un qu'une nouvelle version est disponible et que vous en avez besoin.

Chercher l'adresse du responsable d'un paquet peut être fastidieux. Heureusement, il existe un alias de courrier simple, paquet@packages.debian.org, qui fournit un moyen d'envoyer un courrier à un responsable, quelle que soit son adresse (ou ses adresses). Remplacez paquet par le nom du paquet source ou binaire.

Vous pouvez également vouloir contacter les personnes inscrites à un paquet source donné à l’aide de Suivi de paquets Debian (Debian Package Tracker). Vous pouvez le faire en utilisant l'adresse paquet@packages.qa.debian.org.

7.4. Gestion des responsables non joignables

Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer que le responsable est toujours actif et qu'il continue à travailler sur ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il n'ait pas démissionné du système. D'un autre côté, il est possible qu'il ait simplement besoin d'un rappel.

Il y a un système simple (la base de données MIA) dans laquelle les informations sur les responsables supposés manquant à l'appel (Missing In Action) sont enregistrées. Quand un membre du groupe QA` contacte un responsable inactif ou trouve plus d'informations sur celui-ci, un enregistrement dans la base de données MIA a lieu. Ce système est disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut être interrogé avec mia-query. Utilisez mia-query --help pour voir comment interroger la base de données. Si aucune information n'a encore été enregistrée sur un responsable inactif ou si vous pouvez ajouter plus d'informations, vous devriez utiliser la procédure suivante.

La première étape est de contacter poliment le responsable et d'attendre une réponse pendant un temps raisonnable. Il est assez difficile de définir ce qu'est un temps raisonnable, mais il est important de prendre en compte que la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait être d'envoyer un rappel après deux semaines.

Une adresse de courriel non valable est une violation de la politique de Debian. Si un courriel est rejeté (bounce), veuillez soumettre un bogue pour le paquet et informer la base de données MIA.

Si le responsable ne répond pas après quatre semaines (un mois), on peut supposer qu'il n'y aura probablement pas de réponse. Si cela se produit, vous devriez poursuivre vos investigations et essayer de réunir toutes les informations utiles sur ce responsable. Cela inclut :

• les informations echelon disponibles dans la base de données LDAP des développeurs, qui indiquent quand le développeur a envoyé un message pour la dernière fois sur une liste de diffusion Debian (cela inclut les envois vers les listes debian-devel-changes@lists.debian.org). Pensez aussi à vérifier si le responsable est indiqué comme en vacances dans la base de données ;

• le nombre de paquets de ce responsable et l'état de ces paquets. En particulier, reste-t-il des bogues empêchant l'intégration des paquets dans la distribution qui sont ouverts depuis des lustres ? De plus, combien de bogues y a-t-il en général ? Un autre renseignement important est si les paquets ont subi des NMU, et si oui, par qui ;

• est-ce que le responsable est actif en dehors de Debian ? Par exemple, il peut avoir envoyé des messages récemment à des listes de diffusion non-Debian ou des groupes de discussion ;

Un problème particulier est représenté par les paquets parrainés — le responsable n'est pas un développeur Debian officiel. Les informations echelon ne sont pas disponibles pour les personnes parrainées, par exemple ; vous devez donc trouver et contacter le responsable Debian qui a réellement envoyé le paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de toute façon et il sait probablement ce qui s'est passé avec la personne qu'il parraine.

Il est également permis d'envoyer une demande à debian-devel@lists.debian.org demandant si quelqu'un a des informations sur le responsable manquant. Veuillez mettre en copie (CC) la personne en question.

Une fois réunies toutes ces informations, vous pouvez contacter mia@qa.debian.org. Les personnes de cet alias utiliseront les informations que vous aurez fournies pour décider comment procéder. Par exemple, elles peuvent abandonner tout ou partie des paquets du responsable. Si un paquet a subi une NMU, elles peuvent préférer contacter le responsable ayant fait cette NMU avant de déclarer le paquet orphelin — il pourrait être intéressé par le paquet.

Un dernier mot : veuillez rester poli. Tout le monde est volontaire et ne peut dédier l'intégralité de son temps à Debian. Vous n'êtes pas non plus au courant de la situation de la personne impliquée. Elle est peut-être sérieusement malade ou pourrait même nous avoir définitivement quitté — vous ne savez pas qui recevra vos courriers. Imaginez le sentiment d'un proche qui lit un courrier pour la personne décédée, et trouve un message très impoli, de colère et accusateur !

D'un autre côté, bien que nous soyons des bénévoles, le responsable d’un paquet s’est engagé et a donc la responsabilité d’entretenir le paquet. Aussi, vous pouvez faire valoir l’importance du bien collectif — si un responsable n'a plus le temps ou l'envie, il devrait « laisser filer » et donner le paquet à quelqu'un ayant plus de temps ou plus intéressé.

Si vous êtes intéressé pour travailler dans l'équipe MIA, veuillez étudier le fichier README dans /org/qa.debian.org/mia sur qa.debian.org où les détails techniques et les procédures MIA sont documentés et contactez mia@qa.debian.org.

7.5. Interaction avec de futurs développeurs Debian

Le succès de Debian dépend de sa faculté à attirer et conserver de nouveaux et talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous recommandons de vous impliquer dans le processus pour devenir un nouveau responsable. Cette section décrit comment aider les futurs développeurs.

7.5.1. Parrainage de paquets

Parrainer un paquet signifie envoyer un paquet pour un responsable qui n'est pas encore autorisé à le faire lui-même. Ce n'est pas une mince affaire, le parrain doit vérifier l'empaquetage et s'assurer qu'il respecte le haut niveau d'exigence qualité que Debian s'efforce de conserver.

Les développeurs Debian peuvent parrainer des paquets, mais pas les responsables Debian.

Le processus de parrainage d'un paquet est :

1. le responsable prépare un paquet source (.dsc) et le met en ligne quelque part (par exemple sur mentors.debian.net) ou mieux, fournit un lien vers un dépôt public de logiciel de gestion de versions (voir salsa.debian.org : dépôts Git et plateforme de développement collaborative) où le paquet est entretenu.

2. le parrain télécharge (ou extrait du dépôt) le paquet source ;

3. le parrain vérifie le paquet source. En cas de problème, il informe le responsable et lui demande de fournir une version corrigée (le processus reprend à la première étape) ;

4. le parrain ne trouve aucun problème résiduel. Il construit le paquet, le signe, et l'envoie dans Debian.

Avant de se plonger dans les détails du parrainage de paquet, vous devriez vous demander si l'ajout du paquet proposé est profitable à Debian.

Il n'y a pas de règle simple pour répondre à cette question, cela peut dépendre de plusieurs facteurs : le code source amont est-il suffisamment achevé et pas miné de trous de sécurité ? Existe-t-il déjà des paquets qui font la même chose et que donnent les comparaisons avec ce nouveau paquet ? Le paquet a-t-il été demandé par des utilisateurs et le nombre d'utilisateurs est-il significatif ? Les développeurs amont sont-ils actifs ?

Vous devriez également vérifier que le futur responsable sera un bon responsable. A-t-il déjà de l'expérience avec d'autres paquets ? Si oui, réalise-t-il du bon travail avec ceux-ci (contrôlez quelques bogues) ? Est-il familier avec le paquet et son langage de programmation ? A-t-il les compétences nécessaires pour ce paquet ? Si non, est-il capable de les acquérir ?

C'est aussi une bonne idée de savoir comment il se situe par rapport à Debian : est-il en accord avec la philosophie de Debian et a-t-il l'intention de rejoindre Debian ? Étant donné la facilité de devenir un membre de Debian, vous voudrez peut-être n'être le parrain que de personnes qui prévoient de rejoindre Debian. De cette manière, vous savez dès le début que vous n'aurez pas à jouer le rôle de parrain indéfiniment.

7.5.1.1. Parrainage d'un nouveau paquet

Les nouveaux responsables ont souvent quelques difficultés à créer des paquets Debian — cela est bien compréhensible. Ils feront des erreurs. C'est pourquoi le parrainage d'un tout nouveau paquet dans Debian demande une inspection minutieuse de l'empaquetage. Parfois plusieurs itérations seront nécessaires avant que le paquet ne soit assez bon pour être envoyé dans Debian. Ainsi, être un parrain signifie être un mentor.

Ne parrainez jamais de paquet sans l'avoir vérifié. La vérification de nouveau paquet réalisée par les responsables de l'archive veille principalement à ce que le logiciel soit vraiment libre. Bien sûr, ils tombent parfois sur des problèmes d'empaquetage, mais ça ne devrait vraiment pas arriver. Il est de votre responsabilité de vérifier que le paquet envoyé est compatible avec les principes du logiciel libre selon Debian et qu'il est de bonne qualité.

La construction du paquet et l'essai du logiciel fait partie de la vérification, mais ça ne suffit pas. La suite de cette section est une liste non exhaustive de points à vérifier lors de votre contrôle. [1]

• Vérifiez que l'archive source fournie est la même que celle distribuée par l'auteur amont (quand les sources ont été réempaquetées pour Debian, créez vous-même l'archive modifiée).

• Exécutez lintian (consulter lintian). De nombreux problèmes usuels seront découverts. Prenez soin de vérifier que tous les contrôles de lintian ignorés par le responsable sont pleinement justifiés.

• Exécutez licensecheck (qui fait partie de devscripts) et vérifiez que debian/copyright ait l'air correct et exhaustif. Recherchez des problèmes de licence (comme des fichiers avec « All rights reserved » — tous droits réservés — en en-tête, ou ayant une licence non compatible avec les principes du logiciel libre selon Debian). grep -ri peut vous aider ici.

• Construisez le paquet avec pbuilder (ou n'importe quel outil du même genre, consultez pbuilder) pour vérifier que les dépendances de constructions sont exhaustives.

• Relisez debian/control : est-il conforme aux meilleures pratiques (consultez Meilleures pratiques pour debian/control) ? Les dépendances sont elles exhaustives ?

• Relisez debian/rules : est-il conforme aux meilleures pratiques (consultez Meilleures pratiques pour debian/rules) ? Pouvez-vous apporter quelques améliorations ?

• Relisez les scripts du responsable (preinst, postinst, prerm, postrm, config) : est-ce que preinst et postrm fonctionneront si les dépendances ne sont pas installées ? Est-ce que tous les scripts sont idempotents (c'est-à-dire peuvent-ils être exécutés plusieurs fois sans conséquences) ?

• Vérifiez toutes les modifications des fichiers amont (dans .diff.gz, debian/patches/ ou directement dans l'archive debian pour les fichiers binaires). Sont-elles justifiées ? Sont-elles correctement documentées (conformément à DEP-3 pour les correctifs) ?

• Pour chaque fichier, demandez-vous pourquoi le fichier est là et si c'est la bonne façon d'atteindre le but voulu. Est-ce que le responsable suit les meilleurs pratiques d'empaquetage (consultez Meilleures pratiques d'empaquetage) ?

• Construisez les paquets, installez-les et essayez le logiciel. Vérifiez de pouvoir supprimer et purger les paquets. Essayez-les si possible avec piuparts.

Si la vérification n'a révélé aucun problème, vous pouvez construire le paquet et l'envoyer dans Debian. Rappelez-vous que même sans être le responsable du paquet, le parrain est toujours responsable de ce qu'il envoie dans Debian. C'est pourquoi vous devriez suivre le paquet (cf. Suivi de paquets Debian (Debian Package Tracker)).

Remarquez que vous ne devriez pas avoir à modifier le paquet source pour mettre votre nom dans les fichiers changelog ou control. Le champ Maintainer du fichier control et le fichier changelog devraient afficher la personne qui a fait l'empaquetage, c'est-à-dire, le filleul. Ainsi, ils recevront tous les courriers du système de suivi des bogues (BTS).

À la place, vous devriez indiquer à dpkg-buildpackage d'utiliser votre clef en signature. L'option -k le permet :

dpkg-buildpackage -kKEY-ID

Si vous utilisez debuild et debsign, vous pouvez même le configurer de façon permanente dans ~/.devscripts :

DEBSIGN_KEYID=KEY-ID

7.5.1.2. Parrainage de la mise à jour d'un paquet existant

Vous pourrez en général supposer que le paquet a déjà été vérifié complètement. Au lieu de recommencer depuis le début, vous devriez analyser précautionneusement les différences entre la version actuelle et la nouvelle version préparée par le responsable. Si vous n'avez pas fait la vérification initiale vous-même, vous pourriez tout de même regarder de plus près au cas où elle aurait été négligée.

Afin de comparer les différences, il vous faudra les deux paquets. Téléchargez la version actuelle du paquet source (avec apt-get source) et reconstruisez-le (ou téléchargez les paquets binaires actuels avec aptitude download). Téléchargez le paquet source à parrainer (normalement avec dget).

Lisez la nouvelle entrée du journal de modification, elle devrait vous apprendre ce que vous devriez trouver lors de la vérification. L'outil principal à utiliser est debdiff (du paquet devscripts), vous pouvez l'exécuter avec deux paquets source (fichiers .dsc), deux paquets binaires, ou deux fichiers .changes (seront alors comparés tous les paquets binaires présents dans le fichier .changes).

Si vous comparez les paquets source (à l'exception des fichiers amont dans le cas d'une nouvelle version amont, en filtrant par exemple la sortie de debdiff avec filterdiff -i '*/debian/*'), vous devez comprendre toutes les modifications et elles devraient être convenablement documentées dans le journal de modifications Debian.

Si tout est correct, construisez le paquet et comparez les paquets binaires pour vérifier que les modifications du paquet source n'ont pas des conséquences inattendues (comme certains fichiers supprimés par erreur, des dépendances manquantes, etc.).

Vous pourriez consulter le système de suivi des paquets (consultez Suivi de paquets Debian (Debian Package Tracker)) pour vérifier que le responsable n'a rien oublié d'important. Des mises à jour de traductions pourraient attendre d'être intégrées dans le BTS. Le paquet pourrait avoir été la cible d'une NMU précédente et le responsable pourrait avoir oublié d'intégrer les modifications apportées. Un bogue critique pour la publication oublié pourrait empêcher la migration vers testing. Si vous trouvez quelque chose à améliorer, il est temps de le signaler pour que le responsable puisse s'améliorer la prochaine fois, et ainsi lui donner l'opportunité de mieux comprendre ses responsabilités.

Si vous n'avez pas trouvé de problème majeur, envoyez la nouvelle version. Sinon, demandez au responsable de fournir une version corrigée.

7.5.2. Granting upload permissions to DMs

After a Debian Maintainer's key has been added to the debian-maintainers keyring, a Debian Developer may grant upload permissions to the DM for specific packages by uploading a signed dak command to ftp.upload.debian.org as described in the FTP-Master's announcement to debian-devel.

This process can be simplified with the help of the dcut command from the dput-ng package. Note that this does not work with the dcut command from the dput package!

For example:

dcut dm --uid 0xfedcba9876543210 --allow nano --deny bash

If the DM's key is not in the keyring package yet but in the DD's local keyring, use the --force option and the fingerprint, without spaces and, in this special case, without the 0x prefix and in all uppercase:

dcut --force dm --uid FEDCBA9876543210FEDCBA9876543210 --allow nano

7.5.3. Recommandation d'un nouveau développeur

Les recommandations pour un futur développeur sont disponibles sur le site web de Debian.

7.5.4. Gestion des nouvelles candidatures

La liste de contrôle pour les responsables de candidature est disponible sur le site web de Debian.

[1]

D'autres vérifications sont disponibles dans le wiki où plusieurs développeurs partagent leurs propres listes de contrôle de parrainage.

8. Internationalisation et traduction

Debian prend en charge un nombre toujours croissant de langues naturelles. Même si l'anglais est votre langue maternelle et que vous ne parlez pas d'autre langue, il est de votre devoir de responsable d'être conscient des problèmes d'internationalisation (abrégé en i18n à cause des 18 lettres entre le « i » et le « n » de « internationalisation »). C'est pourquoi, même si des programmes seulement en anglais vous suffisent, vous devriez lire la majeure partie de ce chapitre.

Selon l'introduction à l'i18n de Tomohiro KUBOTA, «I18N (internationalisation) signifie la modification d'un logiciel ou des technologies liées pour que ce logiciel puisse potentiellement gérer plusieurs langues, la personnalisation et d'autres différences» alors que « L10N (localisation) signifie l'implémentation dans une langue spécifique pour un logiciel déjà internationalisé».

La l10n et l'i18n sont interconnectées, mais les difficultés liées à chacune sont très différentes. Il n'est pas vraiment difficile de permettre à un programme de changer la langue dans laquelle sont affichés les textes selon les paramètres de l'utilisateur, mais il est très coûteux en temps de traduire réellement ces messages. D'un autre côté, définir le codage des caractères est trivial, mais adapter le code pour utiliser des codages de caractères différents est un problème vraiment difficile.

En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas de règle générale, il n'y a pas réellement d'infrastructure centralisée pour la l10n dans Debian qui puisse être comparée au mécanisme buildd pour le portage. Le plus gros du travail doit donc être réalisé manuellement.

8.1. Gestion des traductions au sein de Debian

La gestion des traductions des textes contenus dans un paquet est encore une tâche manuelle et le processus dépend du type de texte que vous désirez voir traduit.

For program messages, the gettext infrastructure is used most of the time. Often the translation is handled upstream within projects like the Free Translation Project, the GNOME Translation Project or the KDE Localization project. The only centralized resources within Debian are the Central Debian translation statistics, where you can find some statistics about the translation files found in the actual packages and download those files.

Les descriptions de paquets sont traduites depuis plusieurs années et les responsables n'ont rien à faire de particulier pour gérer les traductions de descriptions de paquets; les traducteurs peuvent utiliser le projet de traduction des descriptions de Debian (DDTP).

For debconf templates, maintainers should use the po-debconf package to ease the work of translators. Some statistics can be found on the Central Debian translation statistics site.

Pour les pages web, chaque équipe l10n a accès au système de gestion de versions correspondant et les statistiques sont disponibles sur le site central des statistiques de traduction Debian.

Pour la documentation globale à propos de Debian, le processus est plus ou moins le même que pour les pages web (les traducteurs ont accès au système de gestion de versions), mais il n'y a pas de page de statistiques.

Another part of i18n work is package-specific documentation (man pages, info documents, other formats). At least the man page translations are po-based as most other things mentioned above.

8.2. FAQ I18N et L10N pour les responsables

Voici une liste des problèmes que les responsables peuvent rencontrer concernant l'i18n et la l10n. Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de consensus sur ces points au sein de Debian et que ce ne sont que des conseils. Si vous avez une meilleure idée pour un problème donné ou si vous êtes en désaccord avec certains points, vous êtes libre de fournir vos impressions pour que ce document puisse être amélioré.

8.2.1. Comment faire en sorte qu'un texte soit traduit

To translate package descriptions, you have nothing to do; the DDTP infrastructure will dispatch the material to translate to volunteers with no need for interaction on your part.

For all other material (debconf templates, gettext files, man pages, or other documentation), the best solution is to ask on debian-i18n for a translation in different languages. Some translation team members are subscribed to this list, and they will take care of the needed coordination, to get the material translated and reviewed. Once they are done, you will get your translated document from them in your mailbox or via a wishlist bugreport. It is also recommended, to use the po-debconf tools for i18n integration.

8.2.2. Comment faire en sorte qu'une traduction donnée soit relue

De temps en temps, des personnes indépendantes traduiront certains textes inclus dans votre paquet et vous demanderont d'inclure la traduction dans le paquet. Cela peut devenir problématique si vous n'êtes pas familier avec la langue donnée. C'est une bonne idée d'envoyer le document à la liste de diffusion l10n correspondante en demandant une relecture. Une fois celle-ci faite, vous pourrez avoir une meilleure confiance en la qualité de la traduction et l'inclure sans crainte dans votre paquet.

8.2.3. Comment faire en sorte qu'une traduction donnée soit mise à jour

Si vous avez certaines traductions d'un texte donné qui traînent, chaque fois que vous mettez à jour l'original, vous devriez demander au précédent traducteur de mettre à jour sa traduction avec vos nouveaux changements. Gardez à l'esprit que cette tâche demande du temps ; au moins une semaine pour obtenir une mise à jour relue.

Si le traducteur ne répond pas, vous pouvez demander de l'aide sur la liste de diffusion correspondante. Si tout échoue, n'oubliez pas de mettre un avertissement dans le document traduit, indiquant que la traduction est un peu obsolète et que le lecteur devrait se référer au document d'origine si possible.

Évitez de supprimer complètement une traduction à cause de son obsolescence. Un vieux document est souvent mieux que pas de documentation du tout pour les personnes non anglophones.

8.2.4. Comment gérer un rapport de bogue concernant une traduction

La meilleure solution peut être de marquer le bogue comme transmis au développeur amont (forwarded) et de faire suivre le bogue à la fois au précédent traducteur et à son équipe (en utilisant la liste de diffusion debian-l10n-XXX correspondante).

8.3. FAQ I18N et L10N pour les traducteurs

Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de procédure générale dans Debian concernant ces points et que, dans tous les cas, vous devriez collaborer avec votre équipe et les responsables des paquets.

8.3.1. Comment aider l'effort de traduction

Choisissez ce que vous désirez traduire, assurez-vous que personne ne travaille déjà dessus (en utilisant votre liste de diffusion debian-l10n-XXX), traduisez-le, faites-le relire par d'autres personnes dont c'est également la langue maternelle sur votre liste de diffusion l10n et fournissez-le au responsable du paquet (voir le point suivant).

8.3.2. Comment fournir une traduction pour inclusion dans un paquet

Assurez-vous que votre traduction est correcte (en demandant une relecture sur votre liste de discussion l10n) avant de la fournir pour inclusion. Cela fera gagner du temps à tout le monde et évitera le chaos qui résulterait d'avoir plusieurs versions du même document dans les rapports de bogue.

La meilleure solution est de créer un rapport de bogue standard contenant la traduction sur le paquet. Assurez-vous d'utiliser les deux étiquettes patch et l10n, et n'utilisez pas une gravité supérieure à wishlist, car l'absence de traduction n'a jamais empêché un programme de fonctionner.

8.4. Meilleures pratiques actuelles concernant la l10n

• En tant que responsable, ne modifiez jamais les traductions en aucune façon (même pour reformater l'affichage) sans demander à la liste de diffusion l10n correspondante. Vous risquez, par exemple, de casser l'encodage du fichier en agissant ainsi. De plus, ce que vous considérez comme une erreur peut être correct (ou même nécessaire) pour une langue donnée.

• En tant que traducteur, si vous trouvez une erreur dans le texte d'origine, assurez-vous de l'indiquer. Les traducteurs sont souvent les lecteurs les plus attentifs d'un texte donné et s'ils ne signalent pas les erreurs découvertes, personne ne le fera.

• Dans tous les cas, rappelez-vous que le problème principal avec la l10n est qu'elle demande la coopération de plusieurs personnes et qu'il est très facile de démarrer une guerre incendiaire à propos de petits problèmes dus à des incompréhensions. Donc, si vous avez des problèmes avec votre interlocuteur, demandez de l'aide sur la liste de diffusion l10n correspondante, sur debian-i18n ou même sur debian-devel (attention, cependant, les discussions sur la l10n tournent très souvent à l'incendie sur cette liste :)

• En tous cas, la coopération ne peut être atteinte qu'avec un respect mutuel.

1. Aperçu des outils du responsable Debian

Cette section contient un aperçu rapide des outils dont dispose le responsable. Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide des outils les plus utilisés.

Les outils du responsable Debian sont destinés à aider les responsables et libérer leur temps pour des tâches plus cruciales. Comme le dit Larry Wall, « il y a plus d'une façon de le faire ».

Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas. Debian n'a pas de position officielle sur la question ; tout outil conviendra du moment qu'il fait le boulot. C'est pourquoi cette section n'a pas été conçue pour indiquer à chacun quel outil il doit utiliser ou comment il devrait faire pour gérer sa charge de responsable. Elle n'est pas non plus destinée à favoriser l'utilisation d'un outil aux dépens d'un autre.

Most of the descriptions of these packages come from the actual package descriptions themselves. Further information can be found in the package documentation itself. You can also see more info with the command apt-cache show package-name.

1.1. Outils de base

Les outils suivants sont pratiquement nécessaires à tout responsable.

1.1.1. dpkg-dev

dpkg-dev contient les outils (y compris dpkg-source) nécessaires pour dépaqueter, construire, et envoyer les paquets source Debian. Ces utilitaires fournissent les fonctionnalités de bas niveau indispensables pour créer et manipuler les paquets ; en tant que tels, ils sont essentiels à tout responsable Debian.

1.1.2. debconf

debconf fournit une interface unifiée pour configurer les paquets de façon interactive. Il est indépendant de l'interface et permet une configuration en mode texte, par une interface HTML ou par boîtes de dialogue. D'autres types d'interface peuvent être ajoutés sous forme de modules.

Vous en trouverez la documentation dans le paquet debconf-doc.

Beaucoup pensent que ce système devrait être utilisé pour tout paquet nécessitant une configuration interactive, cf. Gestion de la configuration avec debconf. debconf n'est pas requis par la Charte Debian pour le moment, mais cela pourrait changer.

1.1.3. fakeroot

fakeroot simule les privilèges de root. Cela permet de fabriquer un paquet sans être root (en général, les paquets installent des fichiers appartenant à root). Si vous avez installé fakeroot, dpkg-buildpackage l’utilisera automatiquement.

1.2. Contrôle de paquets (« lint »)

Selon le « Free On-line Dictionary of Computing » (FOLDOC), « lint » est « un outil de traitement de langage C qui contient beaucoup plus de tests complets sur le code qu’ont habituellement les compilateurs C ». Les outils de contrôle de paquets aident les responsables à découvrir automatiquement les problèmes habituels et les violations de Charte dans leurs paquets.

1.2.1. lintian

lintian dissèque les paquets pour y repérer des bogues et des manquements aux règles de développement. Il contient des tests automatisés pour vérifier de nombreuses règles et quelques erreurs courantes.

Vous devriez récupérer la dernière version de lintian depuis unstable régulièrement et vérifier tous vos paquets. Notez que l'option -i donne des explications détaillées sur la signification de chaque erreur, la partie concernée dans la Charte et le moyen habituel de régler le problème.

Voir Tests du paquet pour plus d'informations sur comment et quand utiliser lintian.

Vous pouvez aussi obtenir un résumé de tous les problèmes signalés par lintian sur vos paquets en https://lintian.debian.org/. Ces rapports contiennent la sortie de la dernière version de lintian pour l'ensemble de la distribution de développement (unstable).

1.2.2. lintian-brush

lintian-brush fournit un ensemble de scripts qui peuvent corriger automatiquement plus de 80 problèmes trouvés par lintian dans les paquets Debian.

Il est fournit avec un script d'enveloppe qui appelle les scripts, met à jour le journal des modifications (si on le souhaite) et envoie chaque révision à la gestion de version.

1.2.3. piuparts

piuparts est l'outil de test d'installation, de mise à niveau et de retrait de paquets .deb.

piuparts s'assure que les paquets .deb gèrent correctement leur installation, leur mise à niveau et leur retrait. Il le fait en créant une installation minimale de Debian dans un chroot et en installant, mettant à niveau et retirant les paquets dans cet environnement, puis en comparant l'état de l'arborescence des répertoires avant et après. piuparts rapporte tous les fichiers qui ont été ajoutés, retirés ou modifiés durant ce processus.

piuparts est censé être un outil d'assurance qualité pour les gens qui créent des paquets .deb afin de les tester avant leur envoi dans l'archive Debian.

1.2.4. debdiff

debdiff (du paquet devscripts, devscripts) compare les listes de fichiers ainsi que les fichiers de contrôle de deux paquets. C'est un simple test de régression qui peut aider à remarquer si le nombre de paquets binaires a changé depuis le dernier envoi ou si autre chose a changé dans le fichier de contrôle. Bien sûr, certains des changements indiqués sont normaux, mais cela peut aider à empêcher différents accidents.

Vous pouvez l'exécuter sur un couple de paquets binaires :

debdiff package_1-1_arch.deb package_2-1_arch.deb

Ou même sur un couple de fichiers de changements :

debdiff package_1-1_arch.changes package_2-1_arch.changes

Pour plus d'informations, veuillez consulter debdiff 1.

1.2.5. diffoscope

diffoscope fournit une comparaison en profondeur de fichiers, d'archives et de répertoires.

diffoscope essaie d'explorer à fond ce qui rend différents des fichiers ou des répertoires. Il décompresse les archives de façon récursive de toute nature et transforme divers formats binaires en une forme plus lisible pour les comparer.

Développé à l'origine pour comparer deux fichiers .deb ou deux fichiers changes, il peut maintenant comparer deux fichiers d'archives, des images ISO ou des PDF aussi facilement et prend en charge un grand éventail de types de fichier.

Les différences peuvent être affichées dans des rapports au format texte ou HTML, ou comme une sortie JSON.

1.2.6. duck

duck, le « Debian Url ChecKer » (vérificateur d'URL de Debian), traite plusieurs champs des fichiers debian/control, debian/upstream, debian/copyright, debian/patches/* et systemd.unit, et vérifie la validité des URL, des liens VCS et des domaines d'adresse de courrier électronique qui s'y trouvent.

1.2.7. adequate

adequate vérifie les paquets installés sur la machine et rapporte les bogues et les manquements aux règles de développement.

Les vérifications suivantes sont actuellement implémentées :

• liens symboliques cassés

• fichier de copyright absent

• fichiers de configuration obsolètes

• modules Python pas compilés en pseudocode

• binaires de /bin et /sbin requérant des bibliothèques de /usr/lib

• bibliothèques absentes, symboles non définis, non correspondances de symboles de taille

• conflits de licence

• collisions de noms de programme

• alternatives absentes

• interpréteurs et détecteurs de binfmt absents

• dépendances à pkg-config absentes

1.2.8. i18nspector

i18nspector est un outil pour rechercher les problèmes courants dans les fichiers de modèles de traduction (POT), de catalogues de messages (PO) et de catalogues de messages compilés (MO).

1.2.9. cme

cme est un outil issu du paquet libconfig-model-dpkg-perl et c'est un éditeur avec validation de fichiers source de dpkg. Consultez la description du paquet pour voir ce qu'il peut faire.

1.2.10. licensecheck

licensecheck tente de déterminer la licence qui s'applique aux fichiers qui lui sont soumis en recherchant au début du fichier des textes appartenant à diverses licences.

1.2.11. blhc

blhc est un outil qui vérifie les journaux de constructions à la recherche des attributs de renforcement (« hardening ») manquants.

1.3. Assistance pour debian/rules

Des outils de construction de paquets facilitent le processus d'écriture du fichier debian/rules. Scripts d'assistance contient plus d'informations sur l'intérêt de les utiliser ou non.

1.3.1. debhelper

debhelper regroupe un ensemble de programmes pouvant être utilisés dans debian/rules pour automatiser les tâches courantes relatives à la construction de paquets Debian binaires. debhelper inclut des programmes pour installer différents fichiers, les compresser, ajuster leurs droits et intégrer votre paquet dans le système de menu Debian.

À la différence d'autres approches, debhelper est divisé en plusieurs petits utilitaires simples qui agissent de manière cohérente. Ce découpage permet un contrôle des opérations plus fin que certains des autres outils pour debian/rules.

Il existe aussi un certain nombre de petites extensions debhelper trop éphémères pour être documentées ici. La plupart seront listées avec apt-cache search ^dh-.

Lors du choix du niveau de compatibilité de debhelper de votre paquet, il conviendrait de choisir le niveau de compatibilité le plus élevé pris en charge par la version stable la plus récente. L'utilisation d'un niveau de compatibilité plus élevé est réservée aux cas où des fonctionnalités particulières sont nécessaires et ne sont fournies que par ce niveau de compatibilité.

In the past the compatibility level was defined in debian/compat, however nowadays it is much better to not use that but rather to use a versioned build-dependency like debhelper-compat (=12).

1.3.2. dh-make

dh-make contient dh_make, un programme qui crée un squelette de fichiers nécessaires à la construction d'un paquet Debian à partir d'une arborescence source. Comme le nom le suggère, dh_make est une réécriture de debmake et ses fichiers modèles utilisent les programmes dh_* de debhelper.

Quoique les fichiers de règles fabriqués par dh_make constituent en général une base suffisante pour un paquet fonctionnel, ce ne sont que les fondations : la charge incombe toujours au responsable d'affiner les fichiers générés et de rendre le paquet complètement fonctionnel et en conformité avec la Charte.

1.3.3. equivs

equivs est encore un assistant. Il est souvent conseillé pour un usage local, pour faire un paquet qui satisfasse des dépendances. Il est aussi parfois utilisé pour faire des « métapaquets », dont l'unique objet est de dépendre d'autres paquets.

1.4. Construction de paquets

Les paquets suivants facilitent le processus de construction des paquets, en contrôlant globalement dpkg-buildpackage ainsi que la gestion des tâches.

1.4.1. git-buildpackage

git-buildpackage permet de mettre à jour ou de récupérer des paquets source dans un référentiel Git, il permet de fabriquer un paquet Debian depuis le dépôt Git et assiste le responsable lors de l'intégration de modifications amont dans le dépôt.

Ce paquet fournit l'infrastructure facilitant l'utilisation de Git pour le responsable Debian. Il permet de conserver des branches Git distinctes pour les distributions stable, unstable et éventuellement experimental et de bénéficier des avantages d'un système de gestion de versions.

1.4.2. debootstrap

debootstrap permet d'amorcer un système Debian de base à n'importe quel endroit de votre système de fichiers. « Système de base » signifie ici le strict minimum de paquets nécessaires pour fonctionner et installer le reste du système.

Un système comme celui-ci peut être utilisé de nombreuses façons différentes. Par exemple, avec chroot, vous pouvez y tester les dépendances de construction. Vous pouvez aussi vérifier le comportement d'un paquet installé dans un environnement minimal. Les automates de constructions « chrootés » utilisent ce paquet ; voir ci-après.

1.4.3. pbuilder

pbuilder construit un système « chrooté » et compile des paquets dans ce système. C'est très pratique pour vérifier que les dépendances de compilation d'un paquet sont correctes et pour s'assurer qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le paquet résultant.

cowbuilder est un outil similaire, qui accélère le processus de construction en utilisant un système de fichiers COW sur n’importe quel système de fichiers standard Linux.

1.4.4. sbuild

sbuild est un autre compilateur automatique. Il peut également être utilisé dans un environnement « chrooté ». Il peut être utilisé seul ou comme partie d'un environnement de compilation distribué en réseau. Comme le précédent, il fait partie du système utilisé par les porteurs pour construire des paquets binaires pour toutes les architectures disponibles. Voir wanna-build pour plus d'informations et https://buildd.debian.org/pour voir le système en fonctionnement.

1.5. Envoi de paquets

Les paquets suivants aident à automatiser ou simplifier le processus d'envoi de paquets dans l'archive officielle.

1.5.1. dupload

dupload is a package and a script to automatically upload Debian packages to the Debian archive, to log the upload, and to optionally send mail about the upload of a package. It supports various kinds of hooks to extend its functionality, and can be configured for new upload locations or methods, although by default it provides various hooks performing checks and comes configured with all Debian upload locations.

1.5.2. dput

The dput package and script do much the same thing as dupload, but in a different way. Out of the box it supports to run dinstall in dry-run mode after the upload.

1.5.3. dcut

dcut (du paquet dput, dput) permet de supprimer des fichiers du répertoire d'envoi FTP.

1.6. Automatisation de la maintenance

Les outils suivants permettent d'automatiser les différentes tâches de maintenance en ajoutant des entrées au journal des modifications ou des lignes de signatures, en cherchant des bogues depuis Emacs et en utilisant le fichier officiel config.sub le plus récent.

1.6.1. devscripts

devscripts is a package containing wrappers and tools that are very helpful for maintaining your Debian packages. Example scripts include debchange (or its alias, dch), which manipulates your debian/changelog file from the command-line, and debuild, which is a wrapper around dpkg-buildpackage. The bts utility is also very helpful to update the state of bug reports on the command line. uscan can be used to watch for new upstream versions of your packages (see https://wiki.debian.org/debian/watch for more info on that). suspicious-source outputs a list of files which are not common source files.

Voir la page de manuel devscripts 1 pour une liste complète des scripts disponibles.

1.6.2. reportbug

reportbug est un outil conçu pour rendre relativement faciles les rapports de bogues dans Debian et dans les distributions dérivées. Parmi ces fonctionnalités :

• intégration à mutt et aux lecteurs de mail mh/nmh ;

• accès aux rapports de bogues non résolus pour faciliter l'identification des problèmes qui ont été déjà rapportés ;

• vérification automatique des dernières versions des paquets.

reportbug est conçu pour une utilisation sur des systèmes où un agent de transport de courrier électronique est installé ; néanmoins, on peut éditer le fichier de configuration et envoyer les rapports avec n'importe quel serveur de courrier électronique.

Ce paquet fournit aussi le script querybts pour naviguer dans le système de suivi des bogues de Debian.

1.6.3. autotools-dev

autotools-dev contient les meilleurs pratiques pour les responsables des paquets qui utilisent autoconf ou automake. Il contient également les fichiers canoniques config.sub et config.guess, connus pour fonctionner avec tous les portages Debian.

1.6.4. dpkg-repack

dpkg-repack crée un paquet Debian à partir d'un paquet déjà installé. Si des changements ont été effectués sur le paquet depuis qu'il a été installé (des fichiers de /etc modifiés par exemple), le nouveau paquet héritera de ces changements.

Cet utilitaire peut faciliter la copie de paquet d'un ordinateur à un autre, ou la recréation de paquets installés sur un système qui ne sont plus disponibles ailleurs, ou pour sauvegarder l'état actuel d'un paquet avant de le mettre à niveau.

1.6.5. alien

alien convertit des paquets binaires entre différents formats de paquets, y compris des paquets Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris et Slackware.

1.6.6. dpkg-dev-el

dpkg-dev-el fournit un paquet Emacs Lisp pour faciliter l'édition des fichiers du répertoire debian. Par exemple, des fonctions pratiques permettent de lister les bogues actuels d'un paquet et de finaliser la dernière entrée d'un fichier debian/changelog.

1.6.7. dpkg-depcheck

dpkg-depcheck (du paquet devscripts, devscripts) exécute une commande sous strace pour déterminer tous les paquets utilisés par la commande.

Pour les paquets Debian, c'est utile pour créer une ligne Build-Depends d'un nouveau paquet : exécuter le processus de compilation avec dpkg-depcheck fournira une bonne première approximation des dépendances de compilation. Par exemple :

dpkg-depcheck -b debian/rules build

dpkg-depcheck peut aussi être utilisé pour vérifier les dépendances d'exécution, d'autant plus si le paquet utilise exec 2 pour exécuter d'autres programmes.

Pour plus d'informations, veuillez voir dpkg-depcheck 1.

1.6.8. debputy

The debputy tools is new since 2024. While its main purpose is to offer a new Debian package build paradigm, it includes subcommands that can be used on any existing Debian package to validate the correctness of most of the files in debian/*, and in many cases also automatically fix them.

To check correctness of files in debian/* run:

debputy lint --spellcheck

To format debian/control and debian/tests/control files

debputy reformat --style black

Using the reformat command obsoletes using wrap-and-sort -ast.

The debputy tool also includes a language server which, when integrated with a code editor, can give real-time feedback on the correctness of files in debian/* while editing them.

For more information please see debputy 1.

1.7. Outils de portage

Les outils suivants sont pratiques pour les porteurs et la compilation croisée (cross-compilation).

1.7.1. dpkg-cross

dpkg-cross est un outil qui installe les bibliothèques et les en-têtes nécessaires à une compilation croisée d'une manière similaire à dpkg. De plus, les fonctionnalités de dpkg-buildpackage et dpkg-shlibdeps ont été améliorées pour accepter les compilations croisées.

1.8. Documentation et information

Les paquets suivants fournissent des informations pour les responsables ou de l'aide pour construire de la documentation.

1.8.1. debian-policy

Le paquet debian-policy fournit la charte Debian (Debian Policy Manual) ainsi que les documents qui lui sont associés et qui sont :

• la charte Debian

• la norme d'organisation du système de fichiers (FHS) ;

• les règles pour Menu dans Debian ;

• les règles pour Perl dans Debian ;

• la spécification de gestion de configuration pour Debian ;

• La spécification lisible par une machine des fichiers debian/copyright ;

• autopkgtest : tests automatiques de paquets Debian ;

• la liste officielle des noms de paquets virtuels ;

• la liste de contrôle de la Charte pour mettre à niveau les paquets.

Le manuel de la charte Debian contientt l'ensemble des règles relatives aux paquets et des détails du mécanisme de l'empaquetage. Il couvre tout, des options requises de gcc à la manière dont les scripts du responsable (postinst, etc.) fonctionnent, aux sections et priorités des paquets, etc.

Le fichier /usr/share/doc/debian-policy/upgrading-checklist.txt.gz qui liste les modifications entre les versions de la charte est aussi pertinent.

1.8.2. doc-debian

doc-debian fournit une nombreuse documentation utile spécifique à Debian :

• le Manifeste Linux de Debian ;

• la constitution du projet Debian ;

• le contrat social de Debian ;

• les principes du logiciel libre selon Debian ;

• la documentation du système de suivi des bogues Debian ;

• l'introduction aux listes de diffusion de Debian.

1.8.3. developers-reference

Le paquet developers-reference fournit le document que vous êtes en train de lire, le guide de référence du développeur pour Debian, un ensemble de règles et de bonnes pratiques qui ont été établies par et pour la communauté des développeurs Debian.

1.8.4. maint-guide

Le paquet maint-guide fournit le guide du nouveau responsable Debian.

Ce document tente de décrire aux utilisateurs ordinaires de Debian et aux développeurs en devenir, la construction d'un paquet Debian. Il utilise un langage peu technique et est complété par des exemples pratiques.

1.8.5. debmake-doc

The debmake-doc package contains the Guide for Debian Maintainers.

This document is newer than Debian New Maintainers' Guide and intends to replace it. The Guide for Debian Maintainers caters to those learning Debian packaging and covers a wide range of topics and tools, along with plenty of examples about various types of packaging issues.

1.8.6. packaging-tutorial

Ce tutoriel est une introduction à la construction de paquet Debian. Il apprend aux développeurs en devenir comment modifier un paquet existant, comment créer ses propres paquets et comment interagir avec la communauté Debian.

En plus du tutoriel principal, il fournit trois exercices pratiques sur la modification du paquet grep, l'empaquetage du jeu gnujump et enfin sur l'empaquetage d'une bibliothèque Java.

1.8.7. how-can-i-help

how-can-i-help montre les possibilités de contribuer à Debian. Il est ancré à APT pour lister ces opportunités de contributions à Debian sur des paquets installés localement (paquets orphelins, bogues marqués « newcomer » — pour débutant) après chaque invocation d'APT. Le programme peut aussi bien être exécuté directement et, dans ce cas, il liste la totalité des contributions possibles (et pas seulement les plus récentes).

1.8.8. docbook-xml

docbook-xml provides the DocBook XML DTDs, which are commonly used for Debian documentation (as is the older debiandoc SGML DTD).

docbook-xsl fournit les fichiers XSL pour construire et décliner les sources en de multiples formats de sortie. Vous devriez utiliser un processeur de ligne de commande XSLT, tel que xsltproc, pour utiliser les feuilles de style XSL. La documentation des feuilles de style est disponible dans les nombreux paquets docbook-xsl-doc-*.

Pour fabriquer des PDF à partir des FO (Formatting Objects), il faut un processeur de FO comme xmlroff ou fop. Un autre outil comme dblatex peut générer des PDF à partir des XML pour DocBook.

1.8.9. debiandoc-sgml

debiandoc-sgml fournit la définition de type de document (Document Type Definition ou DTD) SGML pour DebianDoc, souvent utilisé pour la documentation Debian, mais est maintenant déconseillé (docbook-xml ou python3-sphinx devraient être utilisés à la place).

1.8.10. debian-keyring

Contains the public OpenPGP keys of Debian Developers and Maintainers. See Gestion de clé publique and the package documentation for more information.

1.8.11. debian-el

debian-el fournit un mode Emacs pour afficher les paquets binaires Debian. Il vous permet d'examiner un paquet sans le décompresser.