dokumentacja

Zacznij pracę z Zenit Linux

Od pierwszego rozruchu do zbudowania własnego obrazu — najkrótsza droga przez cały ekosystem.

Instalacja

Pobierz obraz ISO i nagraj go na nośnik rozruchowy:

sha256sum -c zenit-linux-0.3.0-x86_64.iso.sha256
dd if=zenit-linux-0.3.0-x86_64.iso of=/dev/sdX bs=4M status=progress conv=fsync

Uruchom z nośnika, wybierz środowisko graficzne (jeśli obraz je oferuje — patrz installer/config.hcl) i przejdź przez kreator instalatora.

Podstawy zpm

Po instalacji zpm jest już dostępny. Wyszukuje pakiety we wszystkich skonfigurowanych backendach naraz:

zpm install neovim
zpm install neovim -> apt      # wymuś konkretny backend
zpm list --all                   # widok ujednolicony: baza + pokwitowania
zpm doctor --fix                 # diagnostyka + automatyczne naprawy

Ekosystem own to alternatywa dla curl … | sh — narzędzia Zenit (w tym samo zpm) są instalowane z weryfikacją podpisu GPG, nie ślepym zaufaniem do skryptu z internetu.

package.list

Moduły zlb opisują pakiety w formacie HCL, jeden blok na pakiet — to ta sama składnia, którą zlb czyta z modules/*/package.list:

package "kernel" {
  backend     = "own"
  variant     = "testing"
  description = "jądro z brancha testing zamiast domyślnego stable"
}

package "git" {
  backend = "apt"
  variant = "debian.testing"   # instalacja cross-distro, izolowana w kontenerze
}

package "curl" {}               # backend/wariant domyślny z distro.hcl

Wariant (variant) zmienia znaczenie w zależności od backendu: dla own to branch narzędzia w own-repository, dla reszty backendów — docelowa dystrybucja. Instalacja cross-distro nigdy nie dotyka natywnej bazy pakietów hosta: zpm uruchamia ją w izolowanym, efemerycznym kontenerze i scala tylko wynikowy diff.

Szukasz konkretnego pakietu z ekosystemu own? Zobacz przeglądarkę pakietów.

Toolset: GNU czy Zenit

distro.hcl pozwala wybrać, jakie narzędzia bazowe (odpowiedniki coreutils/util-linux/findutils) trafiają do obrazu — klasyczny GNU, albo własny, minimalny zestaw Zenit (36 narzędzi z zenit-base/tools/, każde jako osobny pakiet own):

toolset {
  profile        = "zenit"   # albo "gnu" (domyślne)
  allow_override = true       # czy --toolset= na builda może to nadpisać
}

Pojedynczy build można nadpisać bez zmiany distro.hcl:

zlb build rootfs --toolset=zenit

zlb dokłada odpowiedni moduł (modules/toolset-gnu/ albo modules/toolset-zenit/) do listy pakietów automatycznie — nie trzeba go wymieniać ręcznie w modules.include.

Instalator: środowiska graficzne i języki

Twórca dystrybucji opartej o Zenit steruje kreatorem instalacji przez installer/config.hcl w korzeniu repozytorium:

installer {
  desktop_selector = true
  desktops         = ["gnome", "plasma", "xfce", "all", "none"]
  default_desktop  = "gnome"

  locales         = ["pl_PL.UTF-8", "en_US.UTF-8", "de_DE.UTF-8"]
  default_locale  = "pl_PL.UTF-8"
}

branding {
  icon   = "icon-no-bg.png"   # względem overlays/branding/
  banner = "banner.png"
}

Każdy wpis w desktops (poza "none" i sentinelem "all") musi mieć odpowiadający katalog modules/desktop-<id>/package.list z metapakietem tego środowiska — zlb manifest validate to sprawdza przed zbudowaniem ISO. "all" włącza dodatkowo pełny, wbudowany katalog instalatora (GNOME, Plasma, Xfce, COSMIC, Budgie, MATE, LXQt, Deepin, Enlightenment i własne środowiska Zenit — ZDE i Blue Environment, oba na razie jako zapowiedzi) — użytkownik może wtedy wybrać dowolne z nich, nie tylko te jawnie wymienione w desktops. Instalator sam obsługuje siedem języków interfejsu (polski, angielski, niemiecki, francuski, hiszpański, włoski, ukraiński) niezależnie od tego, ile lokalizacji oferuje dana dystrybucja w locales.

Plik i pliki brandingu (overlays/branding/) są osadzane w obrazie ISO przez zlb i odczytywane przez instalator w trakcie działania — ten sam mechanizm działa niezależnie od tego, czy instalator jest uruchamiany automatycznie z GRUB-a, ręcznie z sesji live, czy w trybie tekstowym (--server, bez GUI) na maszynie bez środowiska graficznego.

Budowanie własnego obrazu

  1. Sklonuj repozytorium zenit (albo zrób widelec).
  2. Dostosuj distro.hcl — nazwę, wersję, listę architektur.
  3. Edytuj modules/core/package.list według potrzeb.
  4. Zwaliduj manifest: zlb manifest validate.
  5. Zbuduj: zlb build all --arch x86_64.

Wynik ląduje w out/ — ISO, obraz OCI i sumy sha256, dokładnie jak w oficjalnym CI. Szczegóły na stronie buildera.

Publikacja własnego pakietu (zpk)

zpk — builder pakietów .zpk — prowadzi od pomysłu do pull requesta w rejestrze pakietów trzema poleceniami:

  1. zpk init — tworzy zpk.build (metadane pakietu w HCL) i przykładowy skrypt budujący.
  2. zpk build --release — buduje .zpk dla każdej architektury z package.arch, licząc sumy sha256.
  3. zpk schedule-release — otwiera pull request do own-repository z nowym albo zaktualizowanym wpisem.
zpk init
$EDITOR zpk.build recipe.janet
zpk build --release --verbose
zpk schedule-release --branch=testing

Ostatnie polecenie otwiera pull request — stamtąd zpm na każdym systemie zobaczy Twój pakiet po najbliższym zpm refresh. Format natywny .zpk to podpisany manifest z sumą sha256 archiwum i każdego pliku w środku — zpm install pakiet.zpk weryfikuje integralność przed rozpakowaniem.

Wolisz przejść przez to pytanie-po-pytaniu? zpk tutorial-release to interaktywny kreator z wyborem języka (ZPK_LANG=pl).

Diagnostyka

Coś nie zgadza się między tym, co zpm myśli, że zainstalowało, a stanem faktycznym na dysku:

zpm doctor          # diagnoza: baza SQLite vs pokwitowania vs stan realny
zpm doctor --fix     # napraw to, co bezpieczne (nigdy nie instaluje/usuwa pakietów)
Pełna referencja poleceń: strona podręcznika man zpm w repozytorium, albo zpm --help.