Uwaga: Oryginał jest nowszy niż to tłumaczenie.
Zarys działania sieci autobuilder
Sercem systemu jest baza wanna-build, która zawiera informacje o wersjach oraz stanach pakietów. quinn-diff porównuje listę pakietów dla docelowej architektury z listą pakietów źródłowych po każdej aktualizacji archiwum i dodaje do bazy listę pakietów, które wymagają ponownej kompilacji, ze stanem ustawionym na Needs-Build.
Wszystkie usługi build (może być więcej niż jedna) regularnie odpytują bazę w poszukiwaniu takich pakietów, pobierają część z nich zmieniając jednocześnie ich stan na Building. Oczywiście człowiek także może pobrać taki pakiet np. gdy z jakiegoś powodu automatyczna kompilacja nie jest możliwa. Pokazuje to także drugi cel bazy wanna-build: zapewnia ona, że ta sama wersja pakietu nie będzie budowana ponownie.
Jeśli wszystko pójdzie dobrze, ukończony pakiet może być następnie wysłany, co oznaczane jest kolejnym stanem Uploaded. Po tej operacji pakiet może być ostatecznie zainstalowany w archiwum Debiana, dzięki czemu pojawi się na liście pakietów do aktualizacji dla danej architektury. Lista ta jest dodawana do bazy a występującym na niej pakietom nadawany jest stan Installed w którym pozostają do czasu pojawienia się następnej wersji pakietu źródłowego.
Istnieje jeszcze kilka innych stanów, m.in: stan Failed oznacza, że nie powiodło się zbudowanie pakietu z powodu błędów w źródle i oczekuje się poprawienia tych błedów w następnej wersji (oczywiście po zgłoszeniu błędu). Nowa wersja od razu otrzymuje status Needs-Build ale z ostrzeżeniem, że coś poszło nie tak w poprzedniej wersji. Razem ze stanem zapisywany jest także opis błedu. Stan Dep-Wait jest używany, kiedy pakiet wymaga do kompilacji innych pakietów, ale te nie są jeszcze dostępne i muszą być wcześniej zbudowane. Ten stan zawiera listę wymaganych pakietów, może zwierać wersję tych pakietów, i kiedy wszystkie z nich są już zbudowane, stan danego pakietu jest ponownie zmieniany na Needs-Build.
Jak już wspomniano, usługa build pobiera pakiety do kompilacji z listy. Teraz przyjrzymy się temu bliżej. Jeżeli są jakieś pakiety do zbudowania, używany jest program sbuild do wykonania tej operacji a dla każdej z operacji tworzony jest log, który jest wysyłany do opiekuna usługi. Przegląda on logi i decyduje, co zrobić z pakietem: wysłać, ustawić mu status na Failed lub Dep-Wait, ponowić próbę itp. Jeżeli opiekun wyśle pozytywne potwierdzenie (podpisany plik .changes) usługa przeniesie pakiet do katalogu upload, skąd wszystkie pakiety są wysyłane przez zadanie ustawione w cron.
Przeglądanie plików logu jest jedynym zadaniem dla człowieka w całym procesie, o ile nie wystąpią żadne błędy. Istnieją dwa ważne powody, dla których do tej pory nie zautomatyzowano tego etapu. Po pierwsze, czasami budowanie kończy się wynikiem ``OK``, mimo że faktycznie nie zostało poprawnie ukończone z powodów, które nie są widoczne dla maszyny. Po drugie, bezpośrednie wysyłanie skompilowanych programów wymagałoby na maszynie, na której budowano pakiety, automatycznego podpisywania utworzonych plików kluczem bez ustawionego hasła. Uznano, że jest to poważna luka w bezpieczeństwie, której nie można zaakceptować.
Skrypt sbuild wywołuje standardowe narzędzia Debiana do kompilacji kodów źródłowych. Jest pomocny również w najczęstszych zadaniach, księgowaniu oraz automatycznym instalowaniu zależności wymaganych przez budowany pakiet.
Treść utworzona przez Roman Hodek na potrzeby 6th International Linux-Kongress 1999, delikatnie zaktualizowana przez Philipp Kern w roku 2009, aby dokładniej odzwierciedlić aktualny stan.