User:Wacek/brudnopis Creating packages
Ten artykuł ma na celu pomóc użytkownikom w tworzeniu własnych pakietów przy użyciu "portowego" build system, również do przesyłania w AUR. Obejmuje tworzenie PKGBUILD – pliku opisu budowy pakietu pozyskiwanego przez makepkg
w celu utworzenia pakietu binarnego ze źródeł. Jeśli już posiadasz PKGBUILD
, zobacz makepkg. Aby uzyskać instrukcje dotyczące istniejących zasad i sposobów poprawy jakości opakowań, zobacz Arch packaging standards.
Przegląd
Pakiety w Arch Linux są budowane przy użyciu narzędzia makepkg i informacji przechowywanych w pliku PKGBUILD. Po uruchomieniu makepkg
szuka PKGBUILD
w bieżącym katalogu i postępuje zgodnie z zawartymi w nim instrukcjami, aby uzyskać wymagane pliki i/lub skompilować je do spakowania w pliku pakietu (pkgname.pkg.tar.zst
). Otrzymany pakiet zawiera pliki binarne i instrukcje instalacji gotowe do zainstalowania przez pacmana.
Pakiet Arch to nic innego jak archiwum tar lub „tarball”, skompresowane przy użyciu zstd(1), które zawiera następujące pliki wygenerowane przez makepkg:
- Pliki binarne do zainstalowania.
.PKGINFO
: zawiera wszystkie metadane potrzebne pacman do obsługi pakietów, zależności itp..BUILDINFO
: zawiera informacje potrzebne do powtarzalnych kompilacji. Ten plik jest obecny tylko wtedy, gdy pakiet został zbudowany za pomocą pacman 5.1 lub nowszego. Zobacz INFORMACJE O BUILDINFO(5)..MTREE
: zawiera skróty i znaczniki czasu plików, które są zawarte w lokalnej bazie danych, dzięki czemu pacman może zweryfikować integralność pakietu..INSTALL
: opcjonalny plik używany do wykonywania poleceń po etapie instalacji/aktualizacji/usuwania. (Ten plik jest obecny tylko wtedy, gdy jest określony wPKGBUILD
.).Changelog
: opcjonalny plik przechowywany przez opiekuna pakietu, dokumentujący zmiany w pakiecie. (Nie występuje we wszystkich pakietach.)
Przygotowanie
Wymagane oprogramowanie
Najpierw upewnij się, że niezbędne narzędzia są zainstalowane: grupa pakietów base-devel powinna wystarczyć, zawiera make
i dodatkowe narzędzia potrzebne do kompilacji ze źródeł.
Kluczowym narzędziem do budowania pakietów jest makepkg (dostarczany przez pacman), który wykonuje następujące czynności:
- Sprawdza, czy są zainstalowane zależności pakietów.
- Pobiera plik(i) źródłowy(e) z określonego(ych) serwera(ów).
- Rozpakowuje plik(i) źródłowe.
- Kompiluje oprogramowanie i instaluje je w środowisku fakeroot.
- Usuwa symbole z plików binarnych i bibliotek.
- Generuje plik meta pakietu, który jest dołączony do każdego pakietu.
- Kompresuje środowisko fakeroot do pliku pakietu.
- Przechowuje plik pakietu w skonfigurowanym katalogu docelowym, który domyślnie jest bieżącym katalogiem roboczym.
Pobierz i przetestuj instalację
Pobierz archiwum źródłowe oprogramowania, które chcesz spakować, rozpakuj go i postępuj zgodnie z instrukcjami autora, aby zainstalować program. Zanotuj wszystkie polecenia i/lub kroki potrzebne do skompilowania i zainstalowania. Będziesz powtarzał te same polecenia w pliku PKGBUILD
Większość autorów oprogramowania trzyma się 3-etapowego cyklu kompilacji:
./configure make make install
To dobry moment, aby upewnić się, że program działa poprawnie.
Tworzenie PKGBUILD
Po uruchomieniu makepkg
szuka pliku PKGBUILD
w bieżącym katalogu roboczym. Jeśli go znajdzie, pobiera kod źródłowy oprogramowania i kompiluje go zgodnie z instrukcjami podanymi w pliku PKGBUILD
. Instrukcje muszą być w pełni interpretowalne przez powłokę Bash. Po pomyślnym zakończeniu, wynikowe pliki binarne i metadane pakietu, tj. wersja pakietu i zależności, są pakowane w plik pakietu pkgname.pkg.tar.zst
Nowo utworzony pakiet można zainstalować po prostu za pomocą makepkg --install
, które wywoła pacman w tle, lub bezpośrednio za pomocą pacman -U pkgname.pkg.tar.zst
.
Aby rozpocząć tworzenie nowego pakietu, najpierw utwórz nowy katalog dla pakietu i zmień bieżący katalog na ten. Następnie należy utworzyć plik PKGBUILD
: można użyć prototypu PKGBUILD znajdującego się w /usr/share/pacman/
lub można uruchomić plik PKGBUILD
z innego pakietu. Ten ostatni może być dobrym wyborem, jeśli podobny pakiet już istnieje.
Definiowanie zmiennych PKGBUILD
Przykładowe pliki PKGBUILD znajdują się w /usr/share/pacman/
. Wyjaśnienie możliwych zmiennych PKGBUILD
można znaleźć w artykule PKGBUILD.
makepkg definiuje dwie zmienne, których należy użyć w ramach procesu budowania i instalowania:
srcdir
- Wskazuje to na katalog, w którym makepkg wyodrębnia lub łączy symboliczne wszystkie pliki w tablicy źródłowej.
pkgdir
- Wskazuje to na katalog, w którym makepkg pakuje zainstalowany pakiet, który staje się katalogiem głównym zbudowanego pakietu..
Zawierają one ścieżki bezwzględne, co oznacza, że nie musisz się martwić o swój katalog roboczy, jeśli używasz tych zmiennych właściwie.
build()
and package()
functions, are intended to be non-interactive. Interactive utilities or scripts called in those functions may break makepkg, particularly if it is invoked with build-logging enabled (--log
). (See FS#13214.)Funkcje PKGBUILD
Podczas budowania pakietu makepkg
wywoła pięć następujących funkcji, jeśli zostały one zdefiniowane w PKGBUILD. Funkcja package()
jest wymagana w każdym PKGBUILD i zawsze będzie wywoływana. Jeśli jakakolwiek inna funkcja nie jest zdefiniowana, makepkg po prostu pominie wywołanie tej funkcji.
Podczas kompilacji funkcje są wywoływane w kolejności, w jakiej są tutaj wymienione.
prepare()
Dzięki tej funkcji uruchamiane są polecenia służące do przygotowania źródeł do budowania, takie jak [[Patching in ABS|łatanie]. Ta funkcja działa zaraz po wyodrębnieniu pakietu, przed pkgver() i funkcją budowania. Jeśli ekstrakcja zostanie pominięta (makepkg --noextract
), to prepare()
nie zostanie uruchomione. .
bash -e
mode, meaning any command that exits with a non-zero status will cause the function to exit.pkgver()
pkgver()
uruchamia się po pobraniu, wyodrębnieniu źródeł i wykonaniu metody prepare(). Możesz więc zaktualizować zmienną pkgver podczas etapu makepkg.
Jest to szczególnie przydatne, jeśli tworzysz making git/svn/hg/etc. packages. pakiety, w których proces budowania może pozostać taki sam, ale źródło może być aktualizowane codziennie, nawet co godzinę. Starym sposobem na zrobienie tego było umieszczenie daty w polu pkgver, które, jeśli oprogramowanie nie zostanie zaktualizowane, makepkg nadal będzie je odbudowywać, myśląc, że wersja uległa zmianie. Niektóre przydatne polecenia to git describe
, hg identify -ni
, itp. Przetestuj je przed przesłaniem PKGBUILD, ponieważ awaria funkcji pkgver()
może zatrzymać kompilację.
-
. Używanie sed do poprawienia tego jest powszechne.
build()
Teraz musisz zaimplementować funkcję build()
w pliku PKGBUILD
. Ta funkcja używa typowych poleceń powłoki w składni Bash do automatycznego kompilowania oprogramowania i tworzenia katalogu o nazwie pkg
, w którym ma zostać zainstalowane oprogramowanie. Dzięki temu makepkg może pakować pliki bez konieczności przeszukiwania systemu plików.
Pierwszym krokiem w funkcji build()
jest przejście do katalogu utworzonego przez rozpakowanie archiwum źródłowego. makepkg zmieni bieżący katalog na $srcdir
przed wykonaniem funkcji build()
. Dlatego w większości przypadków, jak sugerowano w /usr/share/pacman/PKGBUILD.proto
, pierwsze polecenie będzie wyglądać tak:
cd "$pkgname-$pkgver"
Teraz musisz wymienić te same polecenia, których użyłeś podczas ręcznej kompilacji oprogramowania. Funkcja build()
w istocie automatyzuje wszystko, co robiłeś ręcznie i kompiluje oprogramowanie w środowisku kompilacji fakeroot. Jeśli oprogramowanie, które pakujesz, używa skryptu konfiguracyjnego, dobrą praktyką jest użycie opcji --prefix=/usr
podczas budowania pakietów dla pacmana. Wiele programów instaluje pliki powiązane z katalogiem /usr/local
, co powinno być wykonywane tylko wtedy, gdy ręcznie budujesz ze źródeł. Wszystkie pakiety Arch Linux powinny używać katalogu /usr
. Jak widać w pliku /usr/share/pacman/PKGBUILD.proto
, następne dwie linie często wyglądają tak:
./configure --prefix=/usr make
build()
function. The build()
function is not required, but the package()
function is.check()
Miejsce na wywołania make check
i podobnych procedur testowych. Zdecydowanie zaleca się posiadanie check()
, ponieważ pomaga to upewnić się, że oprogramowanie zostało poprawnie zbudowane i działa poprawnie z jego zależnościami.
Użytkownicy, którzy go nie potrzebują (i czasami opiekunowie, którzy nie mogą naprawić pakietu, aby to przeszło) mogą go wyłączyć za pomocą BUILDENV+=('!check')
w PKGBUILD/makepkg.conf lub wywołać makepkg
z flagą --nocheck
.
package()
Ostatnim krokiem jest umieszczenie skompilowanych plików w katalogu, z którego makepkg może je pobrać w celu utworzenia pakietu. Domyślnie jest to katalog pkg
— proste środowisko fakeroot. Katalog pkg
replikuje hierarchię głównego systemu plików ścieżek instalacji oprogramowania. Jeśli musisz ręcznie umieścić pliki w katalogu głównym swojego systemu plików, powinieneś zainstalować je w katalogu pkg
w tej samej strukturze katalogów. Na przykład, jeśli chcesz zainstalować plik w /usr/bin
, należy go umieścić w $pkgdir/usr/bin
. Bardzo niewiele procedur instalacyjnych wymaga od użytkownika ręcznego kopiowania dziesiątek plików. Zamiast tego, w przypadku większości programów, wywołanie make install
zrobi to. Ostatnia linia powinna wyglądać następująco, aby poprawnie zainstalować oprogramowanie w katalogu pkg
:
make DESTDIR="$pkgdir/" install
DESTDIR
is not used in the Makefile
; you may need to use prefix
instead. If the package is built with autoconf / automake, use DESTDIR
; this is what is documented in the manuals. If DESTDIR
does not work, try building with make prefix="$pkgdir/usr/" install
. If that does not work, you will have to look further into the install commands that are executed by "make <...> install
".makepkg --repackage
uruchamia tylko funkcję package()
, więc tworzy pakiet bez budowania. Może to zaoszczędzić czas m.in. jeśli zmieniłeś tylko zmienną depends
pakietu.
Testowanie PKGBUILD i pakietu
W trakcie wykonywania polecenia build() build()
, będziesz chciał często testować swoje zmiany, aby upewnić się, że nie ma błędów. Możesz to zrobić za pomocą polecenia makepkg
w katalogu zawierającym plik PKGBUILD
. Z prawidłowo sformatowanym PKGBUILD
, makepkg utworzy pakiet; z uszkodzonym lub niedokończonym PKGBUILD
, zgłosi błąd.
Jeśli makepkg zakończy się pomyślnie, umieści plik o nazwie pkgname-pkgver.pkg.tar.zst
w twoim katalogu roboczym. Ten pakiet można zainstalować za pomocą polecenia pacman -U
. Jednak to, że skompilowano plik pakietu, nie oznacza, że jest on w pełni funkcjonalny. Można sobie wyobrazić, że może zawierać tylko katalog i nie zawierać żadnych plików, jeśli na przykład prefiks został nieprawidłowo określony. Możesz użyć funkcji zapytań pacmana, aby wyświetlić listę plików zawartych w pakiecie i wymaganych zależności za pomocą odpowiednio pacman -Qlp [package file]
i pacman -Qip [package file]
.
Jeśli pakiet wygląda normalnie, to koniec! Jeśli jednak planujesz zwolnić plik PKGBUILD
, konieczne jest sprawdzenie i ponowne sprawdzenie zawartości tablicy depends
.
Upewnij się również, że pliki binarne pakietu faktycznie "działają" bezbłędnie! Wydawanie pakietu, który zawiera wszystkie niezbędne pliki, jest denerwujące, ale zawiesza się z powodu jakiejś niejasnej opcji konfiguracyjnej, która nie działa dobrze z resztą systemu. Jeśli jednak zamierzasz kompilować pakiety tylko dla własnego systemu, nie musisz się zbytnio martwić o ten krok zapewnienia jakości, ponieważ w końcu jesteś jedyną osobą doświadczającą błędów.
Sprawdzanie poprawności pakietu
After testing package functionality check it for errors using namcap:
$ namcap PKGBUILD $ namcap <package file name>.pkg.tar.zst
Namcap will:
- Sprawdź zawartość PKGBUILD pod kątem typowych błędów i hierarchię plików pakietów pod kątem niepotrzebnych/niewłaściwie umieszczonych plików
- Skanuj wszystkie pliki ELF w pakiecie za pomocą
ldd
, automatycznie zgłaszając, których pakietów z wymaganymi bibliotekami współdzielonymi brakuje wdepends
i które można pominąć jako zależności przechodnie - Heurystyczne wyszukiwanie brakujących i nadmiarowych zależności
i wiele więcej.
Nabierz zwyczaju sprawdzania swoich pakietów za pomocą namcap, aby uniknąć konieczności naprawiania najprostszych błędów po przesłaniu pakietu.
Przesyłanie pakietów do AUR
Zapoznaj się z AUR submission guidelines, aby uzyskać szczegółowy opis procesu przesyłania.
Streszczenie
- Pobierz archiwum źródłowe oprogramowania do spakowania.
- Spróbuj skompilować pakiet i zainstalować go w dowolnym katalogu.
- Skopiuj prototyp
/usr/share/pacman/PKGBUILD.proto
i zmień jego nazwę naPKGBUILD
w tymczasowym katalogu roboczym. - Edytuj
PKGBUILD
zgodnie z potrzebami twojego pakietu. - Uruchom
makepkg
i sprawdź, czy pakiet buduje się poprawnie. - Jeśli nie, powtórz poprzednie dwa kroki.
Ostrzeżenia
- Zanim będziesz mógł zautomatyzować proces budowania pakietu, powinieneś był to zrobić ręcznie przynajmniej raz, chyba że „dokładnie” wiesz, co robisz „z góry”, w takim przypadku nie czytałbyś tego w pierwszej kolejności. Niestety, chociaż spora grupa autorów programów trzyma się 3-etapowego cyklu kompilacji „
./configure
;make
;make install
”, nie zawsze tak jest, a sprawy mogą stać się naprawdę brzydkie, jeśli musisz zastosować łatki, aby wszystko w ogóle działało. Ogólna zasada: Jeśli nie możesz skompilować programu ze źródłowego archiwum i sprawić, by instalował się w zdefiniowanym, tymczasowym podkatalogu, nie musisz nawet próbować go pakować. Wmakepkg
nie ma żadnego magicznego sposobu, który sprawia, że problemy ze źródłami znikają.
- W kilku przypadkach pakiety nie są nawet dostępne jako źródła i musisz użyć czegoś takiego jak
sh installer.run
, aby to zadziałało. Będziesz musiał przeprowadzić sporo badań (przeczytaj README, instrukcje INSTALL, strony podręcznika systemowego, być może ebuildy z Gentoo lub innych instalatorów pakietów, być może nawet pliki MAKEFILE lub kod źródłowy), aby to zadziałało. W niektórych naprawdę złych przypadkach musisz edytować pliki źródłowe, aby w ogóle działały. Jednakmakepkg
musi być całkowicie autonomiczny, bez udziału użytkownika. Dlatego jeśli potrzebujesz edytować pliki makefile, być może będziesz musiał zapakować niestandardową łatkę zPKGBUILD
i zainstalować ją z wnętrza funkcjiprepare()
, albo będziesz musiał wydać poleceniesed
z wnętrza funkcjiprepare()
.
Bardziej szczegółowe wytyczne
32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel modules – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust - Security – Shell – VCS – Web – Wine
Generatory PKGBUILD
PKGBUILD dla niektórych pakietów mogą być generowane automatycznie.
- Haskell: cblrepo, arch-hs
- Node.js: nodejs-npm2archAUR
- Python: pipman-gitAUR, pip2arch-gitAUR, python-pypi2pkgbuildAUR
- Ruby: gem2archAUR, pacgemAUR
- Rust: cargo-pkgbuildAUR