CVS webwml/dutch/devel/buildd
Update of /cvs/webwml/webwml/dutch/devel/buildd
In directory gluck:/tmp/cvs-serv26773
Added Files:
index.wml
Log Message:
Initial translation
--- /cvs/webwml/webwml/dutch/devel/buildd/index.wml 2005/04/17 11:05:49 NONE
+++ /cvs/webwml/webwml/dutch/devel/buildd/index.wml 2005/04/17 11:05:49 1.1
#use wml::debian::template title="Autobuilder network" BARETITLE="true"
#use wml::debian::translation-check translation="1.6" maintainer="Wouter Verhelst"
<p>Het autobuilder-netwerk is een Debian-ontwikkeling die het
hercompileren van pakketten voor alle architecturen die <a
href="$(HOME)/ports/">Debian op dit moment ondersteunt</a>,
vergemakkelijkt. Dit network bestaat uit verschillende machines die een
specifiek software-pakket gebruiken wat <em>buildd</em> heet, om
pakketten uit het Debian-archief op te pikken en ze te hercompileren
voor de doelarchitectuur.
<h2>Waarom is het autobuilder-netwerk nodig?</h2>
<p>De Debian-distributie ondersteunt <a href="$(HOME)/ports/">een flink
aantal architecturen</a>, maar de onderhouders van de pakketten
compileren normaliter de binaire pakketten voor slechts één architectuur
(gewoonlijk i386). Ontwikkelaars voor andere architecturen moeten
uitkijken naar nieuwe versies van pakketten en ze hercompileren als ze
up-to-date willen blijven met de Intel-distributie.
<p>Toen Debian/m68k (de eerste niet-Intel port) opgestard werd, werd dit
allemaal manueel gedaan: ontwikkelaars volgden de upload mailinglijst
voor nieuwe pakketten en startten de compilatie van één of meerdere
daarvan op hun systemen. De noodzakelijke coordinatie om te voorkomen
dat pakketten twee keer gecompileerd werden door verschillende personen
werd gedaan via een eigen mailinglijst. Het is duidelijk dat met deze
procedure makkelijk fouten gemaakt worden, terwijl ze ook veel tijd
vraagt. Toch was dit de normale gang van zaken om niet-i386 distributies
up-to-date te houden voor een lange tijd.
<p>Het "build daemon"-systeem automatiseert het meeste van dit proces.
Het bestaat uit een set scripts (geschreven in Perl en Python) die
mettertijd gegroeid zijn om porters te helpen met verschillende
taken. Ze zijn uiteindelijk geëvolueerd in een systeem dat in staat is
om de niet-i386 distributies bijna volautomatisch up-to-date te houden.
<h2>Hoe werkt buildd?</h2>
<p><em>Buildd</em> is de naam die gewoonlijk gegeven wordt aan de
software die gebruikt wordt door het autobuilder-netwerk, maar het
bestaat eigenlijk uit verschillende onderdelen:
<dl>
<dt><a href="http://m68k.debian.org/buildd/getting.html";>wanna-build</a></dt>
<dd>een hulpmiddel dat pakket-(her)compilaties helpt coordineren via een
database die een lijst van pakketten en hun status bijhoudt. Er is één
centrale database per architectuur die per pakket de status, versie, en
nog wat informatie bijhoudt.</dd>
<dt><a href="http://m68k.debian.org/buildd/getting.html";>buildd</a></dt>
<dd>Een daemon die periodiek de database onderhouden door
<em>wanna-build</em> nakijkt, en <em>sbuild</em> aanroept om de
pakketten te compileren. Het kijkt na of compilaties al dan niet
geslaagd zijn, en zal pakketten ook uploaden nadat de compilatielog
goedgekeurd is door de beheerder.</dd>
<dt><a href="http://packages.debian.org/sbuild";>sbuild</a></dt>
<dd>is verantwoordelijk voor de eigenlijke compilatie van pakketten in
geïsoleerde chroot-omgevingen. Het gebruikt hier vooral standaard
Debian-hulpmiddelen voor, maar zorgt ook voor bron-afhankelijkheden en
een aantal andere nukken.</dd>
<dt>quinn-diff</dt>
<dd>Voedt de wanna-build database met nieuwe pakketten. Het vergelijkt
de beschikbare pakketversies voor twee architecturen en toont de
verschillen (zoals die gevonden worden na vergelijken van een Sources-
en een Packages-bestand). Meer informatie over quinn-diff kan <a
href="http://buildd.debian.org/quinn-diff/";>hier</a> gevonden
worden.</dd>
<dt>andrea</dt>
<dd>Een hulpprogramma dat een aantal bron-afhankelijkheden automatisch
genereert, en die informatie samenvoegt met afhankelijkheden die
handmatig toegevoegd zijn.</dd>
</dl>
<p>Al deze onderdelen <a href="operation">werken samen</a> om het
builder-netwerk te laten werken.
<h2>Wat moet een Debian developer doen?</h2>
<p>Eigenlijk moet een gemiddelde Debian developer het buildd-netwerk
niet expliciet gebruiken. Elke keer hij een pakket naar het
Debian-archief uploadt (met een binaire versie voor een bepaalde
architectuur) zal het toegevoegd worden aan de database voor alle
architecturen (in de status <em>Needs-Build</em>). Build machines zullen
de database bevragen voor pakketten in deze status, en zullen routineus
pakketten van die lijst oppikken. De lijst wordt geprioritizeerd op de
vorige compilatiestatus, de prioriteit van het pakket, de sectie, en tot
slot de pakketnaam.
<p>Als de compilatie succesvol is in alle architecturen, dan moet een
pakketbeheerder niets doen. Al deze binaire pakketten worden geuploaded
naar het Debian-archief. Als de compilatie niet succesvol is, dan zal
het pakket een speciale status krijgen (<em>Failed</em>, of
<em>Dep-Wait</em> als ze bron-afhankelijkheden kennen die niet
beschikbaar zijn).
De autobuilder-beheerders zullen pakketten die niet compileren,
nakijken, en informatie sturen naar de pakketbeheerder, gewoonlijk via
het openen van een bug in het Bug Tracking System.
<p>Soms duurt het lang om een pakket te compileren voor een gegeven
architectuur, en houdt dat de migratie naar <a
href="$(HOME)/devel/testing">testing</a> van dat pakket tegen. Helaas
zal het pakket moeten wachten totdat een machine het oppikt. Buildd
beheerders aanvaarden geen vragen om het compileren van een pakket
sneller te laten verlopen vermits de prioriteitslijst al ingesteld is.
Een pakketbeheerder kan echter wel een <a
href="http://db.debian.org/machines.cgi";>Debian ontwikkelingsmachine</a>
benaderen en het pakket daar manueel compileren.
<p>U kan de status van de verschillende compilatiepogingen van de
pakketten die onder het beheer van een bepaalde pakketbeheerder vallen,
bekijken via de <a href="http://buildd.debian.org/bymaint.php";>buildd
logs</a>. Er is ook een link naar deze logs vanuit het "Packages'
Maintainer Overview".
<p>Voor meer informatie over de verschillende statussen waarin een
pakket zich kan bevinden, gelieve <a
href="wanna-build-states">wanna-build-states</a> te lezen.
<h2>Waar kan ik meer informatie vinden?</h2>
<p>Uiteraard zijn zowel de documentatie als de broncode voor deze
verschillende hulpmiddelen de beste manier om uit te vinden hoe het
buildd-netwerk werkt. Daarnaast bevat de sectie <a
href="$(HOME)/doc/manuals/developers-reference/ch-pkgs#s-porting">Porting
and being ported</a> van de <a
href="$(HOME)/doc/manuals/developers-reference/">Debian Developers
Reference</a> aanvullende informatie over hoe het werkt, terwijl het ook
wat informatie bevat over <a
href="$(HOME/doc/manuals/developers-reference/ap-tools#s-tools-builders">pakketcompilatie-</a>
en <a
href="$(HOME)/doc/manuals/developers-reference/ap-tools#s-tools-porting">porteer-hulpmiddelen</a>
die gebruikt worden in het proces van zowel het opzetten als het
onderhouden van het buildd netwerk.
<p>Er zijn een aantal statistieken van het autobuilder-netwerk
beschikbaar op <a href="http://buildd.debian.org/stats/";>de buildd
stats pagina</a>.
<h2>Hoe kan ik mijn eigen auto-builder node opzetten?</h2>
<p>Er kunnen verschillende redenen zijn waarom een ontwikkelaar (of
gebruiker) een autobuilder zou willen opzetten:
<ul>
<li>Om lokaal te testen of de <tt>Build-Depends</em> van een pakket
correct gedefiniëerd zijn (i.e., door het pakket te compileren in de
auto-builder omgeving).
<li>Om te helpen in de ontwikkeling van een port naar een gegeven
architectuur (wanneer autobuilders nodig zijn)
<li>Om de impact van een gegeven compiler-optimalisatie of patch na te
gaan door een grote groep pakketten te hercompileren.
<li>Om hulpmiddelen uit te voeren die pakketten controleren op bekende
vergissingen en die gedraaid moeten in gecompileerde pakket-directories.
Dit is zelfs nodig wanneer men broncode-analyse wilt doen, bijvoorbeeld,
als een workaround voor pakketten die <tt>dpatch</tt> gebruiken.
</ul>
<p>U kan meer informatie vinden over hoe u een <a
href="setting-up">autobuilder moet opzetten</a>.
<hrline/>
<p><small>Deze introductie naar het autobuilder-netwerk werd geschreven
met informatie gegeven dor Christian T. Steigies, Wouter Verhelst,
Andreas Barth, Francesco Paolo Lovergine en Javier
Fernández-Sanguino</small></p>
Reply to: