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.

Pour qu'un paquet soit accepté, vous devriez contacter l'équipe de publication stable avant de l'envoyer. Pour ce faire, soumettez un bogue sur le pseudopaquet release.debian.org en utilisant reportbug avec le correctif que vous avez l'intention d'appliquer à la version du paquet présent dans stable. Il faut toujours détailler précisément le journal de modification pour un envoi vers la distribution stable.

Une mise à jour de paquet pour la distribution stable requiert des soins supplémentaires. Un paquet de cette distribution ne devrait être mis à jour que dans les cas suivants :

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és dans l'archive proposed-updates appropriée quand l'avis est publié. Reportez-vous en Section 5.8.5, « 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 via un envoi ordinaire vers stable.

Il est fortement déconseillé de changer quoi que ce soit de non important car même une modification triviale peut provoquer un bogue.

Les paquets à destination de stable doivent être compilés sur un système qui tourne sous stable, afin de limiter les dépendances aux bibliothèques (et autres paquets) disponibles dans stable ; par exemple, un paquet pour stable qui dépend de bibliothèques uniquement disponibles dans unstable sera rejeté. Modifier les dépendances d'autres paquets (en semant la pagaille avec les champs Provides ou les fichiers shlibs), au risque de rendre d'autres paquets impossible à installer, est fortement déconseillé.

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.

Veuillez consulter les informations de la section relative à testing pour plus de détails.

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 http://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ée 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.

Pour supprimer des paquets, veuillez lire le fichier ftp://ftp.upload.debian.org/pub/UploadQueue/README et le paquet Debian dcut.

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 mise à jour indépendante (« Non-Maintainer Upload » ou NMU), vous pourriez donner quelques jours pour 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é. Ceci 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.

Avec dput, le paramètre --delayed DELAY permet de placer le paquet dans une de ces files d'attente.

N'envoyez jamais un paquet vers la file d'envoi de sécurité oldstable-security, stable-security, etc.) sans avoir obtenu au préalable 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 détails, voir Section 5.8.5, « Gestion des bogues de sécurité ».

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 via 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.

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 via les files d'attente, le démon vous enverra également une notification par courrier électronique.

Ê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 : http://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 http://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 :

# Synthèse hebdomadaire des rapports de bogue qui me concernent
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

Remplacez address par votre adresse officielle de responsable Debian.

Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes vos discussions concernant les bogues sont envoyées au rapporteur du bogue et au bogue lui-même (<123@bugs.debian.org> par exemple). Si vous rédigez un nouveau courrier et si vous ne vous souvenez plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse <123-submitter@bugs.debian.org> pour contacter le rapporteur et enregistrer votre courrier dans le journal du bogue (ce qui signifie que vous n'avez pas besoin d'envoyer une copie du courrier à <123@bugs.debian.org>).

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 Section 5.8.4, « 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.

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 Section 7.1, « 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 :

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 mise à jour indépendante (« non-maintainer upload » ou 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.

Si vous entrez un numéro de bogue incorrect ou si vous oubliez un bogue dans les entrées du fichier changelog, n'hésitez pas à annuler tout dommage que l'erreur a entraîné. Pour rouvrir un bogue fermé par erreur, envoyez une commande reopen XXX à l'adresse de contrôle du système de suivi des bogues, <control@bugs.debian.org>. Pour fermer tous les bogues restants qui ont été corrigés par votre envoi, envoyez le fichier .changes à <XXX-done@bugs.debian.org> où XXX est le numéro du bogue et placez « Version: YYY » et une ligne vide comme deux premières lignes du corps du courrier où YYY est la première version dans laquelle le bogue a été corrigé.

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 Section 6.3, « Meilleures pratiques pour debian/changelog ».

À 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é, de préférence en remplir un ticket sur leur système de suivi de requêtes. Consultez http://wiki.debian.org/rt.debian.org#Security_Team. Sinon, vous pourriez envoyer un courrier à <team@security.debian.org>. n'envoyez pas de paquet pour stable sans contacter l'équipe de sécurité. Les informations utiles comprennent, par exemple :

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é.

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

Pour changer la section d'un paquet, modifiez les informations de contrôle pour le placer 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 valide, 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 5.7, « Section, sous-section et priorité de paquet ».

Pour supprimer complètement un paquet de l'archive (une vieille bibliothèque de compatibilité devenue inutile par exemple), il faudra envoyer un rapport de bogue sur le pseudopaquet ftp.debian.org et demander la suppression du paquet ; comme chaque bogue, il devrait être de gravité normale. Le titre du rapport devrait être de la forme RM: paquet [liste d'architectures] -- raison, où paquet est le paquet à supprimer et raison un court résumé de la raison de la demande. [liste d'architectures] est facultatif, il n'est requis que si la demande ne concerne pas toutes les architectures. Remarquez que reportbug préparera un titre conforme à ces règles lors de la création d'un bogue sur le pseudopaquet ftp.debian.org.

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 http://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.

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. Ceci 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 surpression du paquet, vous devriez changer le titre et réassigner le bogue O: au paquet wnpp plutôt que d'en ouvrir un autre.

Plus d'informations sur ce sujet et autres sujets connexes sont disponibles sur http://wiki.debian.org/ftpmaster_Removals et http://qa.debian.org/howto-remove.html.

Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des autres développeurs sur la liste <debian-devel@lists.debian.org>. Le programme apt-cache du paquet apt pourra aussi vous être utile. La commande apt-cache showpkg paquet vous indiquera, entre autres, les paquets qui dépendent de paquet. Parmi les programmes utiles, citons apt-cache rdepends, apt-rdepends, build-rdeps (du paquet devscripts) et grep-dctrl. Le retrait de paquets orphelins est discuté sur <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.

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 Section 5.9.2, « 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 désirer 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 ceci 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.

Si vous ne pouvez plus maintenir un paquet, il faut en informer les autres et faire le nécessaire pour le marquer orphaned (orphelin). Vous devriez remplacer votre nom par Debian QA Group <packages@qa.debian.org> dans le champ Maintainer du paquet et faire un rapport de bogue sur le pseudopaquet wnpp. Le titre de votre rapport de bogue devrait être « O: paquet -- description courte » pour indiquer que le paquet est orphelin (O signifie « Orphaned » : orphelin). La gravité du bogue sera normal ; si le paquet a une priorité standard ou supérieure, elle devrait être important. Si vous le jugez nécessaire, envoyez une copie à <debian-devel@lists.debian.org> en mettant cette adresse dans le champ X-Debbugs-CC de l'en-tête du message. N'utilisez pas le champ CC sinon le sujet du message ne contiendra pas le numéro du bogue.

Si vous avez simplement l'intention de donner le paquet, mais que vous pouvez conserver sa maintenance pour le moment, vous devriez plutôt soumettre un rapport de bogue sur wnpp intitulé RFA: package -- description courte. RFA signifie « Request For Adoption » (demande d'adoption).

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

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 parce qu'il vous semble négligé n'est pas correct — ce serait un détournement de paquet. Vous pouvez prendre contact avec le responsable actuel et lui demander si vous pouvez prendre en charge ce paquet. Si vous avez le sentiment qu'un responsable est parti sans prévenir (« absent without leave » ou AWOL), veuillez vous reporter à Section 7.4, « Gestion des responsables non joignables ».

Normalement, vous ne pouvez pas adopter un paquet sans l'accord de son responsable. Même s'il vous ignore, ce n'est pas une raison pour le faire. 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 Section 4.10, « Système de suivi des paquets (PTS) » pour recevoir les rapports de bogue. Cependant, assurez-vous que l'ancien responsable n'est pas embêté de recevoir les rapports de bogues en attendant.

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 bogues et problèmes soulevées par les porteurs. Traitez-les courtoisement, comme s'ils étaient co-responsables 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 :

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 Section 5.11.1, « 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.

La manière d'invoquer dpkg-buildpackage est la suivante : dpkg-buildpackage -B -madresse-porteur. Bien sûr, remplacez adresse-porteur par votre adresse électronique. Cette commande construira les parties du paquet qui dépendent de l'architecture, en utilisant la cible binary-arch de 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.

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.

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 :

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.

Par défaut, les paquet de la section non-free ne sont pas construits sur le réseau d'empaqueteurs automatiques (surtout parce que la licence des paquets pourrait l'interdire). Pour permettre à un paquet d'être construit, vous devez suivre les étapes suivantes :

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

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.

Lors de la préparation du correctif, vous devriez connaître les pratiques spécifiques au paquet potentiellement utilisées par le responsable. Les prendre en compte réduit le fardeau d'intégrer les modifications dans les tâches quotidiennes (« workflow ») du paquet et augmente ainsi les chances d'intégration. Un bon endroit pour chercher d'éventuelles pratiques spécifiques est 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 :

Ces délais sont simplement donnés à titre indicatifs. Dans certains cas, de tels 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'accepter 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ême à la liste permissive de NMU (« Low Threshold NMU list »), 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'inscrire au paquet via 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 recommendations 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.

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. Pour cela, une version de la forme +debXYuZ devrait être utilisée, où X et Y sont les numéros de publication majeur et mineur et Z est un compteur qui commence à 1. Lorsqu'un numéro de version n'est pas encore connu (c'est souvent le cas de testing, au début du cycle de publication), le plus petit numéro de publication plus grand que la dernière publication stable doit être utilisé. Par exemple, alors que Lenny (Debian 5.0) est stable, une NMU de sécurité pour un paquet dont la version est 1.5-3 devrait avoir la version 1.5-3+deb50u1, alors qu'une NMU de sécurité vers Squeeze devrait prendre la version 1.5-3+deb60u1. Après la publication de Squeeze, les envois de sécurité vers la distribution testing prendront comme version +deb61uZ, jusqu'à ce qu'il soit établi que la publication devienne Debian 6.1 ou Debian 7.0 (dans ce cas, les envois prendront comme version +deb70uZ).

Attendre une réponse après avoir demandé la permission de procéder à une NMU est inefficace, car cela coûte au demandeur une commutation de contexte (« context switch ») pour revenir sur le problème. La file d'attente DELAYED/ (voir Section 5.6.2, « 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.

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.

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 co-responsable 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.

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 Section 5.10.2.1, « 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 binaire. 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.

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 n'est pas le sien : 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 orphelins (cette information est disponible sur la page du PTS 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 http://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 Section 5.9.5, « Adoption de paquet »).

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 Section 5.12, « Maintenance collective »), mais vous ne voulez pas vous ajouter comme co-responsable (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.

Les paquets sont habituellement installés dans la distribution testing après avoir été suffisamment éprouvés 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.

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 :

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 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 inter-relations 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 http://release.debian.org/migration/ — mais, attention, cette page affiche également des dépendances de construction qui ne sont pas prises en compte par britney.

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 données 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 via 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 facilité, mais il est recommandé de demander l'autorisation des responsables de publication auparavant. Même si un paquet est gelé, des mises à jour par unstable sont possibles si l'envoi dans unstable ne tire pas de nouvelles dépendances.

Les numéros de version sont habituellement choisis en ajoutant le nom de code de la distribution testing et un numéro incrémenté, comme 1.2squeeze1 pour le premier envoi dans testing-proposed-updates du paquet en version 1.2.

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