Uwaga: Oryginał jest nowszy niż to tłumaczenie.

Sieć Autobuilder

Sieć autobuilder to narzędzie Debiana, które zarządza kompilacją pakietów dla wszystkich architektur wspieranych obecnie przez Debiana. Tworzy je kilka maszyn, które używają oprogramowania nazwanego buildd, aby pobierać pakiety z archiwum Debiana i przebudować je na określoną architekturę.

Dlaczego taka sieć jest potrzebna?

Dystrybucja Debian wspiera sporo architektur, ale opiekunowie pakietów zazwyczaj kompilują wersje binarne dla jednej z nich, do której mają dostęp (zazwyczaj i386 lub amd64). Kompilację dla pozostałych architektur przeprowadza się automatycznie upewniając się, że każdy z pakietów został zbudowany tylko raz. Błędy są zapisywane w bazie autobuildera.

Kiedy wystartował port Debian/m68k (pierwszy nie-intelowski port), jego deweloperzy musieli śledzić nowe wersje pakietów i rekompilować je, jeżeli chcieli być na bieżąco z dystrybucją intelowską. Wszystkie te operacje były wykonywane ręcznie: deweloperzy śledzili listy dyskusyjne pod kątem informacji o nowych pakietach, niektóre z nich były brane do zbudowania pakietu na architekturę m68k. Koordynacja prac, aby dany pakiet nie był budowany jednocześnie przez różne osoby, odbywała się poprzez ogłoszenia na liście dyskusyjnej. Oczywistym jest, że taki sposób prac był podatny na błędy i zajmował dużo czasu. Przez długi okres był to jednak standardowy sposób na utrzymanie aktualnej dystrybucji dla architektur innych niż i386.

System usług budowania zautomatyzował większość tego procesu. Składa się on ze zbioru skryptów (napisanych w Perlu i Pythonie), ciągle rozwijanych, które pomagają osobom zajmującym się innymi architekturami w różnych zadaniach. Skrypty te ostatecznie utworzyły system, który jest w stanie prawie automatycznie utrzymać zaktualizowane różne dystrybucje Debiana. Aktualizacje dotyczące bezpieczeństwa są budowane na tych samych maszynach aby zapewnić ich dostępność w odpowiednim czasie.

Jak działa buildd?

Nazwą buildd określa się potocznie oprogramowanie używane przez sieć autobuilder, ale w rzeczywistości składa się ono z kilku elementów:

wanna-build
narzędzie, które pomaga koordynować (prze)budowanie pakietu dzięki bazie danych, która zawiera listę pakietów i ich statusy. Dla każdej architektury istnieje jedna centralna baza danych, która przechowuje informacje o stanie pakietu, wersji oraz inne informacje. Jest zasilana plikami Sources i Packages pobieranymi z różnych archiwów pakietów, które posiada Debian (np. ftp-master czy security-master).
buildd
usługa, która okresowo sprawdza bazy danych zarządzane przez wanna-build i wywołuje sbuild w celu zbudowania pakietów. Po zaakceptowaniu przez administratora buildd wygenerowaneg logu, zbudowane pakiety są wysyłane do odpowiedniego archiwum.
sbuild
odpowiada za właściwą kompilację pakietów w izolowanym środowisku chroot. Zapewnia, że wszystkie wymagane zależności są zainstalowane w środowisku chroot przed rozpoczęciem budowania a następnie uruchamia standardowe narzędzia Debiana aby rozpocząć proces budowania. Log z tego procesu jest zapisywany w bazie logu budowania.

Wszystkie wymienione elementy współpracują razem, aby sieć builder mogła wykonywać swoje zadania.

Co musi zrobić deweloper Debiana?

Tak naprawdę, typowy deweloper Debiana nie musi bezpośrednio używać sieci buildd. Za każdym razem, gdy wyśle pakiet do archiwum (wersję binarną dla podanej architektury), jest on dodawany do bazy danych dla wszystkich architektur (stan jest ustawiany na Needs-Build). Właściwa maszyna wyszukuje w bazie pakiety w tym stanie a następnie, cyklicznie, pobiera je z utworzonej listy. Kolejność listy jest ustalana na podstawie poprzedniego stany kompilacji (w tym out-of-date lub uncompiled), priorytetu, nazwy sekcji oraz pakietu. Ponadto priorytety są dynamicznie korygowane uwzględniając rosnący czas oczekiwania pakietu w kolejce, aby zapobiec sytuacji, w której jakiś pakiet będzie ciągle spychany na koniec kolejki.

Czasami zbudowanie pakietu dla danej architektury może zająć dłuższą chwilę i może spowodować wstrzymanie wejścia pakietu do edycji \testing. Jeśli pakiet wstrzymuje przejście dystrybucji, zazwyczaj, na żądanie Grupy ds. Wydania, korygowana jest wartość priorytetu budowania. Inne tego typu żądania nie są akceptowane, ponieważ rosnący czas oczekiwania w kolejce automatycznie powoduje podniesienie priorytetu.

Można sprawdzić stan budowania poszczególnych pakietów, które należą do określonego opiekuna, przeglądając logi buildd. Są one dostępne także ze strony Opiekuna Pakietu.

Więcej informacji na temat stanów, w jakich może znaleźć się pakiet, znajduje się na stronie wanna-build-states.

Gdzie znaleźć dodatkowe informacje?

Najlepsze źródło informacji o tym, jak działa sieć buildd, to oczywiście dokumentacja oraz kody źródłowe dostępne dla narzędzi wchodzących w skład tego systemu. Dodatkowo, sekcja Portowanie i bycie portującym z Podręcznika Deweloperów Debiana dostarcza wyczerpujących informacji o tym jak działa ten system oraz o pakiecie builders i narzędziach do portowania które są zaangażowane zarówno w procesie ustawiania oraz zarządzania siecią buildd.

Na stronie statystyk buildd dostępne są także niektóre dane dla sieci autobuilder.

Jak uruchomić własny węzeł auto-builder?

Istnieje kilka powodów, dla których deweloper (lub użytkownik) może chcieć skonfigurować i uruchomić własną sieć autobuilder:

Więcej informacji jak ustawić autobuilder znajduje się na tej stronie.

Kontakt z administratorami buildd

Administratorzy odpowiedzialni za buildd-a dla poszczególnych architektur są dostępni pod adresem arch@buildd.debian.org, na przykład i386@buildd.debian.org.


To wprowadzenie do sieci autobuilder zostało napisane z uwzględnieniem uwag dostarczonych przez: Roman Hodek, Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo Lovergine, Javier Fernández-Sanguino, Philipp Kern.