User:Wacek/brudnopis Creating packages

From ArchWiki

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 w PKGBUILD.)
  • .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:

  1. Sprawdza, czy są zainstalowane zależności pakietów.
  2. Pobiera plik(i) źródłowy(e) z określonego(ych) serwera(ów).
  3. Rozpakowuje plik(i) źródłowe.
  4. Kompiluje oprogramowanie i instaluje je w środowisku fakeroot.
  5. Usuwa symbole z plików binarnych i bibliotek.
  6. Generuje plik meta pakietu, który jest dołączony do każdego pakietu.
  7. Kompresuje środowisko fakeroot do pliku pakietu.
  8. 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.

Note: makepkg, and thus the 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. .

Note: (From PKGBUILD(5)) The function is run in 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ę.

Note: pkgver nie może zawierać spacji ani myślników -. 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
Note: If your software does not need to build anything, do not use the 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
Note: It is sometimes the case where 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:

  1. 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
  2. Skanuj wszystkie pliki ELF w pakiecie za pomocą ldd, automatycznie zgłaszając, których pakietów z wymaganymi bibliotekami współdzielonymi brakuje w depends i które można pominąć jako zależności przechodnie
  3. 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

  1. Pobierz archiwum źródłowe oprogramowania do spakowania.
  2. Spróbuj skompilować pakiet i zainstalować go w dowolnym katalogu.
  3. Skopiuj prototyp /usr/share/pacman/PKGBUILD.proto i zmień jego nazwę na PKGBUILD w tymczasowym katalogu roboczym.
  4. Edytuj PKGBUILD zgodnie z potrzebami twojego pakietu.
  5. Uruchom makepkg i sprawdź, czy pakiet buduje się poprawnie.
  6. 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ć. W makepkg 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. Jednak makepkg 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ę z PKGBUILD i zainstalować ją z wnętrza funkcji prepare(), albo będziesz musiał wydać polecenie sed z wnętrza funkcji prepare().

Bardziej szczegółowe wytyczne

Arch package guidelines

32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – Shell – VCS – Web – Wine

Generatory PKGBUILD

PKGBUILD dla niektórych pakietów mogą być generowane automatycznie.

Note: Użytkownicy są nadal odpowiedzialni za zapewnienie, że pakiet spełnia wysokie standardy jakości przed przesłaniem wygenerowanych plików do AUR.

Zobacz też

Retrieved from "https://wiki.archlinux.org/index.php?title=User:Wacek/brudnopis_Creating_packages&oldid=753594"