Wersja 0.8.0 – nowoczesny menedżer pakietów oparty na repozytoriach git, z izolacją sandbox i wsparciem dla aplikacji GUI.
repo.json
HPM instaluje się przez skompilowanie ze źródeł (wymaga Rust i Cargo):
git clone https://github.com/HackerOS-Linux-System/Hacker-Package-Manager.git
cd Hacker-Package-Manager/source-code
cargo build --release
sudo cp target/release/hpm /usr/bin/hpm
sudo mkdir -p /usr/lib/HackerOS/hpm /var/lib/hpm /var/cache/hpm
sudo chmod 755 /usr/bin/hpmPo instalacji możesz uruchomić hpm --help.
| Polecenie | Opis |
|---|---|
hpm refresh | Pobiera najnowszy indeks pakietów z centralnego repozytorium i aktualizuje lokalne kopie repozytoriów git. |
hpm install <pakiet>[@wersja] | Instaluje pakiet (domyślnie najnowszą wersję). |
hpm remove <pakiet>[@wersja] | Usuwa pakiet lub konkretną wersję. |
hpm update | Aktualizuje wszystkie zainstalowane pakiety (z pominięciem przypiętych). |
hpm switch <pakiet> <wersja> | Przełącza aktywną wersję pakietu. |
hpm run <pakiet> <bin> [args...] | Uruchamia binarkę z pakietu w izolowanym sandboxie. |
hpm info <pakiet> | Wyświetla szczegółowe informacje o pakiecie. |
hpm search <fraza> | Przeszukuje nazwy i opisy pakietów. |
hpm list | Lista zainstalowanych pakietów. |
hpm outdated | Pokazuje pakiety, dla których istnieje nowsza wersja. |
hpm pin <pakiet> <wersja> | Przypina wersję (blokuje aktualizację). |
hpm unpin <pakiet> | Usuwa przypięcie z bieżącej wersji. |
hpm verify <pakiet> | Weryfikuje sumę kontrolną zainstalowanego pakietu. |
hpm deps <pakiet>[@wersja] | Wyświetla drzewo zależności. |
Każdy pakiet w HPM to repozytorium git. Wersje są oznaczane tagami (np. v1.0, 1.0). W katalogu głównym repozytorium muszą znajdować się odpowiednie pliki konfiguracyjne.
nazwa-pakietu/
├── LICENSE (opcjonalnie, ale zalecane)
├── src/ (opcjonalnie, kod źródłowy)
├── build.info (skrypt budowania – wykonywalny)
└── info.hk (główny plik metadanych)Po zbudowaniu pakietu, skrypt build.info powinien utworzyć katalog contents/ z docelowymi plikami (np. binarki, biblioteki, pliki konfiguracyjne). To właśnie zawartość contents/ zostanie skopiowana do katalogu store HPM.
info.hk – formatPlik info.hk jest napisany w składni podobnej do TOML. Zawiera następujące sekcje:
[metadata]
name = "nazwa-pakietu"
version = "1.0"
authors = "Imię Nazwisko lub Zespół"
license = "MIT"
[description]
summary = "Krótki opis, max 50 znaków"
long = "Dłuższy opis, może być wieloliniowy"
[build]
commands = ["./build.info"] # lista komend do wykonania w sandboxie
deb_deps = ["build-essential", "libssl-dev"] # pakiety .deb wymagane do budowania
[runtime]
deb_deps = ["libssl3", "libc6"] # pakiety .deb wymagane do uruchomienia
[sandbox]
network = false # dostęp do sieci
gui = false # podstawowe wsparcie GUI (X11)
full_gui = true # pełne wsparcie GUI (X11, Wayland, D-Bus, PulseAudio, /dev/dri)
filesystem = ["/etc/app/config"] # dodatkowe ścieżki do montowania (bind)
dev = false # czy montować /dev (urządzenia)
[bins]
nazwa-binarki = "" # lista binarek (klucz = nazwa pliku w contents/bin)build i runtime są opcjonalne. Jeśli nie ma build.commands, HPM nie będzie budował – zakłada, że contents/ istnieje już w repozytorium (np. dla pakietów binarnych).
build.infoJest to zwykły skrypt powłoki (powinien mieć ustawione prawo wykonywalności). Wykonuje się w sandboxie z zamontowanym katalogiem źródłowym w /app. Jego zadaniem jest utworzenie katalogu /app/contents z ostateczną zawartością pakietu. Przykład:
#!/bin/sh
# kompilacja
gcc src/narzedzie.c -o narzedzie
# utworzenie struktury
mkdir -p contents/bin
mv narzedzie contents/bin/
# ewentualne pliki konfiguracyjne
cp -r config/* contents/HPM potrafi automatycznie instalować brakujące pakiety .deb (przez apt) – zarówno na etapie budowania, jak i na etapie uruchamiania. Użytkownik jest pytany o zgodę przed instalacją. Dzięki temu pakiety mogą wymagać np. libgtk-3-0 dla GUI, a HPM zadba o ich obecność w systemie.
Załóżmy, że tworzymy narzędzie scanme – skaner portów. Repozytorium scanme.git:
scanme/
├── LICENSE (MIT)
├── src/
│ └── scanme.c
├── build.info
└── info.hkbuild.info:
#!/bin/sh
gcc src/scanme.c -o scanme -lpthread
mkdir -p contents/bin
mv scanme contents/bin/info.hk:
[metadata]
name = "scanme"
version = "1.2"
authors = "John Doe"
license = "MIT"
[description]
summary = "Szybki skaner portów"
long = "Narzędzie do skanowania portów TCP/UDP z obsługą wątków."
[build]
commands = ["./build.info"]
deb_deps = ["build-essential"]
[runtime]
deb_deps = ["libc6"]
[sandbox]
network = true
gui = false
filesystem = []
[bins]
scanme = ""Następnie tagujemy wersję: git tag 1.2 i wypychamy do zdalnego repozytorium.
repo.jsonAby HPM wiedział, skąd pobierać pakiety, prowadzona jest centralna lista w pliku JSON dostępnym pod adresem:
https://raw.githubusercontent.com/HackerOS-Linux-System/Hacker-Package-Manager/main/repo/repo.json
(możesz utworzyć własne lustro lub dodać swoje repozytorium do tej listy przez pull request).
repo.json{
"packages": {
"nazwa-pakietu": {
"repo": "https://github.com/użytkownik/nazwa-pakietu.git",
"versions": ["1.0", "1.1", "2.0"]
},
"inny-pakiet": {
"repo": "https://gitlab.com/inny/inny-pakiet.git",
"versions": ["0.9", "1.0"]
}
}
}Pole versions to lista tagów, które HPM ma traktować jako dostępne wersje. Najnowsza wersja (do domyślnej instalacji) to ostatni element listy (zakładając, że lista jest posortowana rosnąco). Możesz podać wszystkie tagi lub tylko wybrane.
git tag 1.0).repo.json (możesz zgłosić pull request do oficjalnego repozytorium HPM).hpm refresh i będą mogli instalować twój pakiet.repo.json i skonfigurować HPM, aby używał innego URL – wystarczy zmienić stałą REPO_JSON_URL w kodzie źródłowym lub dodać opcję konfiguracji (w przyszłych wersjach).
Aby twoje narzędzie było dostępne dla społeczności HPM:
repo.json – możesz to zrobić przez Pull Request w oficjalnym repozytorium HPM.info.hk – dobre opisy ułatwiają wyszukiwanie.Po dodaniu, użytkownicy HPM na całym świecie będą mogli zainstalować twoje oprogramowanie jednym poleceniem: