Pako — menedżer pakietów dla aplikacji linuksowych
Pako to rozwijany przeze mnie menedżer pakietów przeznaczony dla dużych, samodzielnych aplikacji linuksowych. Porządkuje instalowanie i aktualizowanie programów udostępnianych przez producentów jako archiwa, bez wymagania uprawnień administratora.
01
Problem
Duże aplikacje linuksowe są często udostępniane jako kompletne archiwa. Użytkownik musi samodzielnie pobierać pliki, wypakowywać je, konfigurować, instalować kolejne wydania i pilnować, która wersja jest aktywna.
Ręczny proces utrudnia rollback, może pozostawiać stare pliki i nie zapewnia automatycznej kontroli integralności. Przerwana aktualizacja może również uszkodzić aktywną instalację.
02
Rozwiązanie
Pako wprowadza jednolity model oparty na prostych recepturach recipe.toml i pełnych archiwach payload.tar.zst. Pobiera wydanie, sprawdza jego sumę kontrolną i przygotowuje je w wersjonowanym katalogu.
Nowa wersja jest aktywowana dopiero po pomyślnym zakończeniu procesu. Instalacja odbywa się w przestrzeni użytkownika, bez sudo, z zachowaniem stanu potrzebnego do aktualizacji, usunięcia i rollbacku.
03
Architektura
Pako składa się z biblioteki zawierającej logikę instalacji i zarządzania stanem, użytkowego CLI pako oraz narzędzia pako-build. Wspólny rdzeń odpowiada za parsowanie receptur, pobieranie danych, kontrolę integralności i operacje na wersjach.
Rozdzielenie interfejsu poleceń, procesu budowania i logiki domenowej pozwala rozwijać każdy element bez powielania reguł dotyczących pakietów oraz stanu instalacji.
recipe.toml
pako-build
Wspólny rdzeń
Rust library
CLI pako
04
Prosty format pakietu
Receptura recipe.toml opisuje źródło aplikacji, wersję, architekturę, sumę kontrolną, sposób przygotowania payloadu, pliki wykonywalne i integrację ze środowiskiem użytkownika. Gotowe wydanie jest jednym skompresowanym archiwum payload.tar.zst.
Projekt wcześniej eksperymentował z fragmentowaniem danych i packami. Testy pokazały jednak, że dodatkowa złożoność nie zapewniała wystarczających korzyści, dlatego architektura została świadomie uproszczona.
recipe.toml
payload.tar.zst
05
Instalacja i aktualizacja
Pako pobiera metadane i payload, weryfikuje je, a następnie rozpakowuje aplikację do osobnego katalogu wersji. Dopiero kompletne i sprawdzone wydanie może stać się wersją aktywną.
Taki przepływ oddziela przygotowanie od aktywacji. Poprzednia wersja nie musi być nadpisywana w trakcie aktualizacji, dzięki czemu może pozostać dostępna jako punkt powrotu.
Pobranie
Weryfikacja
Przygotowanie wersji
Aktywacja
06
Bezpieczeństwo i niezawodność
Instalacja działa w katalogach użytkownika i nie wymaga uprawnień administratora. Sumy SHA-256 chronią integralność pobranych danych, a wersjonowane katalogi ograniczają ryzyko pozostawienia częściowo zaktualizowanej aplikacji.
Odzyskiwanie stanu po przerwanych operacjach pozostaje jednym z celów projektu. Konkretne zachowania są nadal rozwijane i nie są przedstawiane jako ukończone gwarancje stabilnego wydania.
Poprzednia wersja
app/1.4.0
Nowa wersja
app/1.5.0 → active
07
Wyzwania
Największe wyzwania to zaprojektowanie bezpiecznego procesu instalacji, zarządzanie wersjami bez uprawnień administratora, kontrola integralności i odzyskiwanie po przerwanych operacjach.
Równie ważne są integracja z katalogami XDG, czytelne komunikaty CLI oraz utrzymanie prostego formatu receptur. Projekt regularnie wymaga oceny, czy kolejna funkcja rzeczywiście uzasadnia dodatkową złożoność.
Czego nauczył mnie projekt
Najważniejsze wnioski
Pako rozwija moje doświadczenie w projektowaniu narzędzi systemowych, bezpiecznych operacji na plikach i upraszczaniu architektury na podstawie wyników testów.
Rust i narzędzia systemowe
Projekt wymaga świadomego zarządzania błędami, ścieżkami, procesami i operacjami na plikach w języku Rust.
Integralność danych
Weryfikowanie pobranych metadanych i payloadów jest częścią procesu, a nie dodatkiem wykonywanym po instalacji.
Operacje transakcyjne na plikach
Nowa wersja powinna zostać przygotowana i sprawdzona przed aktywacją, aby ograniczyć ryzyko pozostawienia częściowo zaktualizowanej aplikacji.
Prostota jako decyzja architektoniczna
Testy wcześniejszych pomysłów pokazały, że prosty pełny payload jest lepszym kompromisem dla docelowych aplikacji niż nieuzasadniona złożoność.
Kod i kontekst
Zajrzyj do repozytoriów projektu
Kod źródłowy, dokumentacja i historia rozwoju Pako pozostają publiczne jako materiał referencyjny.