Outline of operation of the autobuilder network
Centraal in het systeem bevindt zich de wanna-build databank, dewelke informatie over pakketversies en -states bijhoudt. quinn-diff 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 Needs-Build krijgen.
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 building 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 wanna-build: het verzekert dat de zelfde versie van een pakket geen twee keer gecompileerd wordt.
Als alles goed gaat, dan kan een afgewerkt pakket later geuploaded worden, wat overeenkomt met een andere status, Uploaded. 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 Installed verkrijgen, waar het blijft tot de volgende versie van het bronpakket verschijnt.
Er zijn verschillende andere statussen; hieronder zijn: Failed, 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 Needs-Build binnengaan, maar met een waarschuwing dat iets mis was met de vorige versie. Samen met deze status wordt een foutbeschrijving opgeslagen. De status Dep-Wait 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 Needs-Build.
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 sbuild 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 Failed of Dep-Wait zetten, en een nieuwe poging doen, enz... Als een positief antwoord (een gesigneerd .changes bestand) ontvangen wordt, dan verplaatst de daemon het pakket naar een upload directory, vanwaar door een cronjob alle pakketten geupload worden.
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.
Het compilatiescript sbuild 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.
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