path: root/french/devel/buildd/index.wml

#use wml::debian::template title="Réseau de serveurs d'empaquetage automatique" BARETITLE="true"
#use wml::debian::translation-check translation="07cf5605b2f918ba0e3c1cd8df22f71f1b641c18" maintainer="David Prévot"

# Translators:
# Mohammed Adnène Trojette, 2005-2007.
# David Prévot, 2010, 2011.

<p>Le réseau de serveurs d'empaquetage automatique est un
développement de Debian qui s'occupe des empaquetages de
paquet pour toutes les architectures que <a href="$(HOME)/ports/">Debian
gère actuellement</a>. Ce réseau est constitué de plusieurs serveurs qui
utilisent un programme empaqueté dédié appelé <em>buildd</em> afin de
récupérer des paquets depuis l'archive Debian et les empaqueter pour
l'architecture cible.</p>

<h2>Pourquoi le réseau de serveurs d'empaquetage automatique est-il
nécessaire&nbsp;?</h2>

<p>La distribution Debian gère <a href="$(HOME)/ports/">pas mal
d'architectures</a>, mais les responsables de paquets construisent
habituellement des versions binaires pour une seule architecture
à laquelle ils ont accès (i386 ou amd64 habituellement).

Les autres constructions sont réalisées automatiquement, en
s'assurant que chaque paquet n'est construit qu'une seule fois.

Les échecs sont suivis dans la base de données du service d'empaquetage.
</p>

<p>Quand le projet Debian/m68k (le premier portage non-Intel) a débuté,
ses développeurs devaient
surveiller les nouvelles versions de paquets et les empaqueter à nouveau
s'ils souhaitaient rester à jour avec la distribution Intel.
Tout ceci était fait à la main&nbsp;: les développeurs surveillaient sur
la liste de diffusion les envois de nouveaux paquets et les récupéraient
pour les construire. Afin qu'aucun paquet ne soit construit deux
fois, la coordination se faisait par des annonces sur la liste de
diffusion. Évidemment, cette procédure menait à des erreurs et prenait du
temps. Ça a pourtant été, pendant longtemps, la méthode habituelle pour
maintenir les distributions non-i386 à niveau.</p>

<p>Le système d'empaquetage automatise la plupart de ces processus.
Il consiste en une série de scripts (écrits en Perl et Python) qui
ont évolué à travers le temps pour aider les porteurs dans diverses
tâches. Ils ont finalement développé un système capable de maintenir
à niveau presque automatiquement les distributions Debian.

Les mises à jour de sécurité sont construites sur le même jeu de
machines pour s'assurer de leur disponibilité en temps utile.
</p>

<h2>Comment fonctionne le service d'empaquetage
«&nbsp;buildd&nbsp;»&nbsp;?</h2>

<p><em>Buildd</em> est le nom usuel que l'on donne aux programmes
utilisés par le réseau de serveurs d'empaquetage automatique, mais il
est en réalité constitué de différentes parties&nbsp;:</p>

<dl>

<dt>wanna-build</dt>
<dd>
Un outil qui aide à la coordination du (ré)empaquetage de paquet à
travers une base de données qui maintient une liste des paquets et de
leurs statuts. Il y a une base de données centrale par architecture qui
stocke les états, les versions et quelques autres informations sur les
paquets.

Elle est alimentée avec les fichiers Sources et Packages récupérés des
diverses archives Debian (par exemple ftp-master et security-master).
</dd>

<dt><a href="https://packages.debian.org/buildd">buildd</a></dt>
<dd>
Un démon qui vérifie périodiquement la base de données maintenue par
<em>wanna-build</em> et appelle <em>sbuild</em> pour construire les
paquets.
Dès que le journal de construction a été validé par l'administrateur,
le paquet est envoyé dans l'archive adéquate.
</dd>

<dt><a href="https://packages.debian.org/sbuild">sbuild</a></dt>
<dd>
Il est responsable de la construction effective des paquets dans des
«&nbsp;chroots&nbsp;».
Il s'assure que toutes les dépendances nécessaires des sources sont
installées avant la construction puis appelle les outils standards
de Debian pour commencer le processus de construction.
Les journaux de construction sont envoyés sur la <a
href="https://buildd.debian.org">base de données des journaux de
construction</a>.
</dd>

</dl>

<p>Toutes ces parties <a href="operation">contribuent</a> ensemble à
faire fonctionner le réseau de serveurs d'empaquetage.</p>

<h2>Que doit faire un développeur Debian&nbsp;?</h2>

<p>Dans les faits, le développeur Debian moyen n'a rien à faire
explicitement pour utiliser le service d'empaquetage. À chaque fois
qu'il envoie un paquet à l'archive (un binaire compilé pour une
architecture donnée), celui-ci est ajouté à la base de données de toutes
les architectures (dans l'état <em>Needs-Build</em>). Les serveurs
d'empaquetage enverront des requêtes à la base de données pour les paquets
qui sont dans cet état, et prendront habituellement les paquets de
cette liste. La liste est priorisée par précédent état de compilation
(soit <em>out-of-date</em>, soit <em>uncompiled</em>),
priorité, section et nom de paquet.
De plus, pour éviter de laisser moisir des paquets en fin de queue,
les priorités sont ajustées dynamiquement en fonction du temps passé
dans la file d'attente.
</p>

<p>Si l'empaquetage réussit sur toutes les architectures, les
responsables n'auront rien à faire. Tous les paquets binaires produits
seront envoyés sur le site principal de l'architecture. Si l'empaquetage
échoue, le paquet entrera dans un état spécial (<em>Build-Attempted</em>
en cas d'erreurs de construction qui n'ont pas été vérifiées,
<em>Failed</em> en cas d'erreurs vérifiées et de bogues soumis au paquet ou
<em>Dep-Wait</em>, s'ils nécessitent des dépendances spécifiques qui ne
sont pas disponibles). Les administrateurs des serveurs d'empaquetage
automatique examineront les paquets dont l'empaquetage échoue et
rapporteront cet échec au responsable, habituellement par l'ouverture
d'un bogue dans le système de suivi des bogues.</p>

<p>Parfois, un paquet met du temps à être empaqueté pour
une architecture donnée et cela bloque son entrée dans <a
href="$(HOME)/devel/testing"><em>testing</em></a>.
Si un paquet retarde une transition, les priorités sont normalement
ajustées à la demande de l'équipe en charge de la publication.
Les autres requêtes seront refusées puisque la priorité augmente
automatiquement en fonction du temps passé dans la file d'attente.
</p>

<p>Vous pouvez vérifier le statut des différentes
tentatives d'empaquetage des paquets qui appartiennent à
n'importe quel responsable donné en jetant un &oelig;il aux <a
href="https://buildd.debian.org/status/">journaux des services
d'empaquetage</a>. Ces journaux sont aussi liés aux pages
récapitulatives des responsables de paquets.</p>

<p>Pour plus d'information sur les différents
états que peut prendre un paquet, veuillez lire <a
href="wanna-build-states"><em>wanna-build-states</em></a>.</p>

<h2>Où puis-je trouver des informations additionnelles&nbsp;?</h2>

<p>Bien entendu, la documentation et le code source disponibles pour
ces différents outils sont le meilleur moyen de bien comprendre comment
fonctionne le réseau d'empaqueteurs. Par ailleurs, la section
<a href="$(HOME)/doc/manuals/developers-reference/pkgs.html#porting">\
Portage</a> de la <a href="$(HOME)/doc/manuals/developers-reference/">\
Référence du développeur Debian</a> fournit des informations
complémentaires sur la manière dont cela fonctionne
et elle fournit aussi quelques infos sur les <a
href="$(HOME)/doc/manuals/developers-reference/tools.html#tools-builders">\
empaqueteurs</a> et les <a
href="$(HOME)/doc/manuals/developers-reference/tools.html#tools-porting">\
outils de portage</a> qui sont impliqués dans les processus
d'installation et de maintenance du réseau de serveurs
d'empaquetage.</p>

<p>Quelques statistiques sur le réseau de serveurs d'empaquetage sont
disponibles sur les <a href="https://buildd.debian.org/stats/">pages de
statistiques des serveurs d'empaquetage</a>.</p>

<h2>Comment puis-je mettre en place mon propre n&oelig;ud
d'empaquetage automatique&nbsp;?</h2>

<p>Il peut y avoir plusieurs raisons pour qu'un développeur (ou qu'un
utilisateur) veuille mettre en place et faire fonctionner un service
d'empaquetage automatique&nbsp;:</p>

<ul>
<li>afin d'aider au développement d'un portage vers une architecture
donnée (quand des serveurs d'empaquetage automatique sont
nécessaires)&nbsp;;</li>
<li>afin d'évaluer l'impact d'une optimisation de compilateur ou d'un
patch donnés sur le réempaquetage d'un large panel de paquets&nbsp;;</li>
<li>afin de lancer des outils d'analyse des paquets pour débusquer des
erreurs connues et qui doivent être lancés sur des paquets construits.
Cela est même nécessaire lorsque l'on fait de l'analyse de code, par
exemple lorsque l'on utilise <tt>dpatch</tt> pour proposer des solutions
de contournement («&nbsp;work-around&nbsp;»).</li>
</ul>

<p>Vous pouvez lire plus d'informations sur la méthode de mise en place
d'un <a href="https://wiki.debian.org/BuilddSetup">serveur
d'empaquetage automatique</a>.</p>

<h2>Contacter les administrateurs «&nbsp;buildd&nbsp;»</h2>

<p>
L'adresse de contact principale des responsables de wanna-build est la 
<email debian-wb-team@lists.debian.org> (<a href="https://lists.debian.org/debian-wb-team/
">liste de diffusion</a>).</p>
<p>
Les administrateurs responsables de l'empaquetage automatique pour une
architecture particulière peuvent être contactés sur
<email arch@buildd.debian.org>, par exemple <email i386@buildd.debian.org>.
</p>

<hrline />

<p><small>Cette introduction au réseau de serveurs d'empaquetage
automatique a été écrite à partir d'extraits fournis par Roman Hodek,
Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo
Lovergine, Javier Fernández-Sanguino et Philipp Kern.</small></p>