[RFR] wml://www.debian.org/dutch/devel/buildd/operation.wml
Dag iedereen,
In de git-opslagplaats webwml werd de vertaling van
dutch/devel/buildd/operation.wml bijgewerkt.
In bijlage de bijgewerkte vertaling en een diff-bestand met de wijzigingen
tegenover de vorige versie.
--
Met vriendelijke groet,
Frans Spiesschaert
diff --git a/dutch/devel/buildd/operation.wml b/dutch/devel/buildd/operation.wml
index ef2d9eae6f6..51c1ed1ad65 100644
--- a/dutch/devel/buildd/operation.wml
+++ b/dutch/devel/buildd/operation.wml
@@ -1,5 +1,5 @@
#use wml::debian::template title="Outline of operation of the autobuilder network" BARETITLE="true"
-#use wml::debian::translation-check translation="4094875c3a7aafc988b5f218b0a629fab415552a"
+#use wml::debian::translation-check translation="848f05ee39ce74ed77b065b215fbbefc6aa4532c"
<p>Centraal in het systeem bevindt zich de <tt>wanna-build</tt>
databank, dewelke informatie over pakketversies en -states bijhoudt.
@@ -67,7 +67,7 @@ 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
+alleen mogelijk zou zijn via het automatisch ondertekenen met OpenPGP van de
resulterende bestanden met een sleutel zonder wachtwoord op de
compilatiemachine. Ik vond dit een onaanvaardbaar
beveiligingsrisico.</p>
#use wml::debian::template title="Outline of operation of the autobuilder network" BARETITLE="true"
#use wml::debian::translation-check translation="848f05ee39ce74ed77b065b215fbbefc6aa4532c"
<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 na elke update van het archief de
pakketlijsten voor de doelarchitectuur met de lijst van bronpakketten,
en werkt een lijst van pakketten die opnieuw gecompileerd moeten worden
bij in de database, waar deze 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 teruggezet naar <tt>Needs-Build</tt>.</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, en
een nieuwe poging doen, enz...
Als een positief antwoord (een gesigneerd <tt>.changes</tt> bestand)
ontvangen wordt, dan verplaatst de daemon het pakket naar een upload directory,
vanwaar door een cronjob alle pakketten geupload 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 ondertekenen met OpenPGP van de
resulterende bestanden met een sleutel zonder wachtwoord op de
compilatiemachine. Ik vond dit een onaanvaardbaar
beveiligingsrisico.</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, en met de automatische installatie van
broncode-afhankelijkheden.</p>
<hr>
<p><small>Inhoud geschreven door Roman Hodek voor het 6e internationale
Linux-Kongress 1999; in 2009 door Philipp Kern voorzichtig bijgewerkt
om beter aan te sluiten bij de huidige realiteit</small></p>
Reply to: