Dlaczego samohostowanie

Jedna zależność zewnętrzna, i to tylko na start

Świeży runner CI nie ma jeszcze niczego z ekosystemu Zenit. Musi skądś wziąć pierwszą binarkę zpm — to jedyny moment (stage0), w którym proces budowania sięga poza siebie, pobierając ją z own-repository. Od tego punktu zpm instaluje resztę ekosystemu — łącznie z samym sobą, żeby przyszłe buildy nie musiały nawet tego jednego kroku.

Ten sam menedżer pakietów, ten sam builder

Obraz, który pobierasz ze strony pobierania, zawiera w środku zpm, zlb i zpk jako zwykłe, zainstalowane pakiety. Uruchomienie zlb build all wewnątrz zainstalowanego Zenita produkuje kolejny obraz Zenita — z tymi samymi narzędziami w środku. To nie jest metafora marketingowa; to dosłowny, sprawdzalny fakt o zawartości obrazu.

Dlaczego to ma znaczenie

• Spójność. Nie ma osobnego "trybu deweloperskiego" builda i "trybu produkcyjnego" — to ten sam zlb, ten sam manifest.
• Przejrzystość. Cały proces budowania da się odtworzyć lokalnie: git clone, zlb build all, gotowe.
• Rozszerzalność. Widelec repozytorium i zmiana distro.hcl wystarczą, żeby powstała nowa dystrybucja oparta o tę samą bazę — bez utrzymywania osobnego forka narzędzi.

Co jeszcze nie jest samohostowane

Uczciwie: kompilator Nim, jądro Linux i podstawowe narzędzia GNU/toolchain wciąż pochodzą spoza projektu — samohostowanie dotyczy warstwy dystrybucji (budowanie obrazu, zarządzanie pakietami, publikacja), nie całego stosu od krzemu po interfejs użytkownika. To świadoma granica, nie przeoczenie.

Licencja i społeczność

Cały ekosystem — zpm, zlb, zpk i sam zenit — jest wolnym oprogramowaniem na licencji GPL-3.0. Kod źródłowy, issue trackery i dyskusje mieszkają na GitHubie organizacji Zenit-Linux.