CVS webwml/dutch/devel/buildd
Update of /cvs/webwml/webwml/dutch/devel/buildd
In directory gluck:/tmp/cvs-serv14216
Added Files:
operation.wml
Log Message:
Initial translation
--- /cvs/webwml/webwml/dutch/devel/buildd/operation.wml 2006/04/26 10:36:48 NONE
+++ /cvs/webwml/webwml/dutch/devel/buildd/operation.wml 2006/04/26 10:36:48 1.1
#use wml::debian::template title="Outline of operation of the autobuilder network" BARETITLE="true"
#use wml::debian::translation-check translation="1.8" maintainer="Wouter Verhelst"
<p>Centraal in het systeem bevindt zich de <tt>wanna-build</tt>
databank, dewelke informatie over pakketversies en -states bijhoudt.
<tt>quinn-diff</tt> vergelijkt elke dag de pakketlijsten voor de
doelarchitectuur tegen de lijst van bronpakketten, en stuurt een lijst
van pakketten die gehercompileerd moeten worden in de database, waar ze
de status <tt>needs-build</tt> krijgen.</p>
<p>Alle build daemons (er kunnen er meerdere zijn) bevragen regelmatig
de databank voor pakketten in deze status en kiezen een aantal van hen
zodat ze de naar de status <tt>building</tt> overgaan. Uiteraard kunnen
ook mensen een pakket kiezen, bijvoorbeeld in speciale gevallen waar
automatische compilatie niet mogelijk is. Hier zien we ook het tweede
doel van <tt>wanna-build</tt>: het verzekert dat de zelfde versie van
een pakket geen twee keer gecompileerd wordt.</p>
<div class="center"><a name="autobuilder34"></a>
<img src="scheme.png" alt="Autobuilder schema">
<p><strong>Figuur:</strong>
Pakket-states en overgangen</p>
</div>
<p>
Als alles goed gaat, dan kan een afgewerkt pakket later geuploaded
worden, wat overeenkomt met een andere status, <tt>uploaded</tt>. Daarna
zal het uiteindelijk geïnstalleerd worden in het Debian-archief zodat
het tevoorschijn komt in de aangepaste pakketlijst voor de
doelarchitectuur. Deze lijst wordt dan samengevoegd met de databank, en
het pakket zal de status <tt>installed</tt> verkrijgen, waar het blijft
tot de volgende versie van het bronpakket verschijnt.</p>
<p>
Er zijn verschillende andere statussen; hieronder zijn: <tt>failed</tt>,
wat gebruikt wordt voor pakketten die niet gecompileerd konden worden
door fouten in de broncode, en waarbij verwacht wordt dat de problemen
opgelost zullen worden in een volgende versie (nadat fouten gemeld
werden, uiteraard). Zulk een nieuwe versie zal meteen
<tt>needs-build</tt> binnengaan, maar met een waarschuwing dat iets mis
was met de vorige versie. Samen met deze status wordt een
foutbeschrijving opgeslagen. De status <tt>dep-wait</tt> wordt gebruikt
wanneer een pakket een ander pakket nodig heeft, maar waarbij deze nog
niet beschikbaar zijn en eerst opnieuw gecompileerd moeten worden. Deze
status slaat de lijst van benodigde pakketten mee op, inclusief
eventuele versies, en wanneer ze allemaal beschikbaar zijn, wordt de
status terug naar <tt>needs-build</tt> gezet.</p>
<p>
Zoals we al gezien hebben neemt de build daemon pakketten uit de
databank om ze te compileren. Laat ons een beetje dichterbij kijken: als
er een aantal pakketten beschikbaar zijn, dan gebruikt het
<tt>sbuild</tt> voor het daadwerkelijke compilatieproces, en wordt voor
elke compilatie een log naar de beheerder van de daemon gestuurd. Hij
controleert de log en beslist wat ermee gedaan moet worden: het
uploaden, het pakket op <tt>failed</tt> of <tt>dep-wait</tt> zetten, een
aantal zaken aan de lijst met afhankelijkheden toevoegen en opnieuw
proberen, enz... Als een positief antwoord ontvangen wordt, dan
verplaatst de daemon het pakket naar een upload directory, vanwaar alle
pakketten door een cronjob geuploaded worden.</p>
<p>
Kijken naar de logbestanden is de enige menselijke interventie in het
hele proces als er zich geen fouten voordoen. Er zijn twee goede redenen
om het proces niet verder te automatiseren: Ten eerste is het zo dat
compilaties soms met een 'OK' resultaat beëindigd worden, maar dat de
compilatie toch mislukte om redenen die voor de machine niet zichtbaar
zijn. Ten tweede is het zo dat het ogenblikkelijk uploaden van pakketten
alleen mogelijk zou zijn via het automatisch PGP-ondertekenen van de
resulterende bestanden met een sleutel zonder wachtwoord op de
compilatiemachine. Ik vond dit een onaanvaardbaar
beveiligingsrisico.</p>
<p>
<p>Het compilatiescript <tt>sbuild</tt> doet niet veel meer dan het
aanroepen van een aantal standaard Debian-tools om de broncode te
compileren. Het helpt ook bij een aantal standaard taken en wat
boekhouding, maar het echt speciale ding aan <tt>sbuild</tt> zijn de
broncode-afhankelijkheden. Dikwijls hebben pakketten andere pakketten
nodig om gecompileerd te kunnen worden, bijvoorbeeld compilers en
bibliotheekbestanden. Het is niet praktisch om al die pakketten ten
allen tijde geïnstalleerd te hebben staan, en het is dikwijls zelfs niet
mogelijk omwille van conflicten. De broncode-afhankelijkheden vertellen
<tt>sbuild</tt> nu gewoon voor elk pakket welke andere pakketten
benodigd zijn. Het kan ze dan automatisch installeren voor de compilatie
uitgevoerd wordt, en ze nadien ook weer verwijderen.<p>
<p>
De lijst van broncode-afhankelijkheden kan ten dele ook automatisch
gegenereerd worden, door naar de lijst van afhankelijkheden van de
binaire pakketten te kijken die door de broncode gegenereerd worden. Dit
is de taak van <tt>andrea</tt>, die de afhankelijkheden in de
i386-pakketlijst analyseert en bibliotheek-pakketten aan namen van
ontwikkelingspakketten koppelt. Het voegt het resultaat ook samen met
handmatige toevoegingen voor zaken die niet automatisch gegenereerd
kunnen worden, zoals compilers of speciale tools.</p>
<hr>
<p><small>Inhoud geschreven door Roman Hodek voor het 6e internationale
Linux-Kongress 1999</small></p>
Reply to: