User:Wacek/brudnopis Creating packages

Ten artykuł ma na celu pomóc użytkownikom w tworzeniu własnych pakietów przy użyciu systemu "portopodobnego" Arch Linux build system, również do przesyłania w AUR. Obejmuje tworzenie pliku PKGBUILD - pliku opisu kompilacji pakietów pobieranego przez makepkg w celu utworzenia pakietu binarnego ze źródła. Jeśli już posiadasz PKGBUILD, zobacz makepkg. Aby uzyskać instrukcje dotyczące istniejących zasad i sposobów poprawy jakości paczki, zobacz Arch packaging standards.

Przegląd

Pakiety w Arch Linux są budowane przy użyciu narzędzia makepkg i informacji przechowywanych w pliku PKGBUILD. Gdy uruchomi się makepkg, wyszukuje PKGBUILD w bieżącym katalogu i postępuje według instrukcji w nim, aby uzyskać wymagane pliki i / lub skompilować je do spakowania w pliku pakietu (pkgname.pkg.tar.xz). Wynikowy pakiet zawiera pliki binarne i instrukcje instalacyjne gotowe do zainstalowania przez pacman.

Pakiet Arch jest niczym więcej jak archiwum tar, lub "tarball" skompresowane przy użyciu xz, które zawiera następujące pliki wygenerowane przez makepkg:

• Pliki binarne do zainstalowania.
• .PKGINFO: zawiera wszystkie metadane potrzebne pacmanowi do radzenia sobie z pakietami, zależnościami itp.
• .BUILDINFO: zawiera informacje potrzebne do odtwarzalnych wersji. Ten plik jest obecny tylko wtedy, gdy pakiet jest zbudowany z pacman 5.1 lub nowszym.
• .MTREE: zawiera skróty i sygnatury czasowe 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.)

Meta pakiety i grupy

Grupa paczek to zbiór powiązanych pakietów, zdefiniowanych przez program pakujący, które można zainstalować lub odinstalować jednocześnie, używając nazwy grupy jako substytutu dla każdej nazwy pojedynczego pakietu. Chociaż grupa nie jest pakietem, może być zainstalowana w sposób podobny do pakietu (zobacz Pacman#Installing package groups i grup PKGBUILD#groups).

Pakiet meta, często (choć nie zawsze) zatytułowany przyrostkiem -meta, zapewnia podobną funkcjonalność do grupy pakietów, ponieważ umożliwia jednoczesne instalowanie lub odinstalowywanie wielu powiązanych pakietów. Pakiety Meta mogą być instalowane podobnie jak inne pakiety (patrz [Pacman#Installing specific packages]]). Jedyną różnicą między pakietem meta a zwykłym pakietem jest to, że pakiet meta jest pusty i istnieje tylko w celu połączenia powiązanych pakietów za pomocą zależności.

Zaletą pakietu meta w porównaniu do grupy jest to, że wszelkie nowe pakiety członkowskie zostaną zainstalowane, gdy sam pakiet meta zostanie zaktualizowany o nowy zestaw zależności. Jest to przeciwieństwo do grupy, w której nowi członkowie grupy nie zostaną automatycznie zainstalowani. Wadą pakietu meta jest to, że nie jest tak elastyczny jak grupa; możesz wybrać członków grupy, których chcesz zainstalować, ale nie możesz wybrać zależności, które chcesz zainstalować. Podobnie możesz odinstalować członków grupy bez konieczności usuwania całej grupy. Jednak nie można usunąć zależności pakietu meta bez konieczności odinstalowania samego pakietu meta.

Przygotowanie

Wymagane oprogramowanie

Po pierwsze, upewnij się, że zainstalowane są niezbędne narzędzia: pakiet {Grp|base-devel}} powinien być wystarczający, zawiera make i dodatkowe narzędzia potrzebne do kompilacji ze źródła.

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 pakietu.
2. Pobiera pliki źródłowe z podanych serwerów.
3. Rozpakowuje pliki ź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 jest domyślnie bieżącym katalogiem roboczym.

Pobierz i przetestuj instalację

Pobierz archiwum źródłowe oprogramowania, które chcesz spakować, wyodrębnij i postępuj zgodnie z instrukcjami autora, aby zainstalować program. Zanotuj wszystkie komendy i / lub kroki potrzebne do skompilowania i zainstalowania. Będziesz powtarzać te same polecenia w pliku PKGBUILD.

Większość twórców oprogramowania trzyma się 3-etapowego cyklu budowy:

./configure
make
make install

To dobry czas, aby upewnić się, że program działa poprawnie.

Tworzenie PKGBUILD

Po uruchomieniu makepkg szuka pliku PKGBUILD w bieżącym katalogu roboczym. Jeśli znajdzie, pobierze kod źródłowy oprogramowania i skompiluje go zgodnie z instrukcjami określonymi w pliku PKGBUILD. Instrukcje muszą być w pełni interpretowalne przez powłokę Bash. Po pomyślnym zakończeniu, powstałe pliki binarne i metadane pakietu, tj. Wersja pakietu i zależności, są pakowane w plik pakietu pkgname.pkg.tar.xz Nowo utworzony pakiet można zainstalować po prostu za pomocą makepkg --install, który wywoła pacman w tle, lub bezpośrednio za pomocą pacman -U pkgname.pkg.tar.xz.

Aby rozpocząć tworzenie nowego pakietu, najpierw utwórz nowy katalog pakietu i zmień katalog bieżący na ten. Następnie należy utworzyć plik PKGBUILD: można użyć prototypu PKGBUILD znalezionego w /usr/share/pacman/ lub można uruchomić z PKGBUILD z innego pakietu. To drugie może być dobrym wyborem, jeśli podobny pakiet już istnieje.

Definiowanie zmiennych PKGBUILD

Przykład PKGBUILD znajdują się w /usr/share/pacman/. Wyjaśnienie możliwych zmiennych PKGBUILD można znaleźć w artykule PKGBUILD.

Wskazuje to na katalog, w którym 'makepkg zawiera pakiet, który staje się katalogiem głównym twojego zbudowanego pakietu.

makepkg definiuje dwie zmienne, których powinieneś użyć jako część procesu budowania i instalacji:

srcdir

Wskazuje to na katalog, w którym makepkg wypakowuje lub łączy symboliczne wszystkie pliki w tablicy źródłowej.

pkgdir

Wskazuje to na katalog, w którym 'makepkg zawiera pakiet, który staje się katalogiem głównym twojego zbudowanego pakietu.

Zawierają one bezwzględne ścieżki, co oznacza, że nie musisz się martwić o swój katalog roboczy, jeśli używasz tych zmiennych poprawnie.

Note: makepkg, a zatem funkcje build() i package(), mają być nieinteraktywne. Interaktywne narzędzia lub skrypty wywoływane w tych funkcjach mogą przerwać makepkg, szczególnie jeśli jest wywoływany z włączonym logowaniem budowania (-L). (Zobacz FS#13214.)

Funkcje PKGBUILD

Istnieje pięć funkcji wymienionych tutaj w kolejności ich wykonywania. Oprócz piątej funkcji, package(), która jest wymagana w każdym PKGBUILD, jeśli jedna funkcja nie istnieje, jest po prostu pomijana.

prepare()

Ta funkcja, polecenia używane do przygotowania źródeł do budowania, są uruchamiane, na przykład patching. Ta funkcja działa zaraz po wypakowaniu pakietu, przed pkgver() i funkcją kompilacji. Jeśli ekstrakcja jest pomijana (makepkg -e), wówczas funkcja prepare() nie jest uruchamiana.

Note: (Z PKGBUILD(5)) Funkcja jest uruchamiana w trybie bash -e, co oznacza, że każde polecenie, które wychodzi z niezerowym stanem, spowoduje wyjście z funkcji..

pkgver()

Funkcja pkgver() działa po pobraniu źródeł, wyodrębnieniu i prepare(). Możesz więc zaktualizować zmienną pkgver podczas etapu makepkg.

Jest to szczególnie przydatne, jeśli tworzysz git /making git/svn/hg/etc. packages, w których proces budowania może pozostać taki sam, ale źródło może być aktualizowane codziennie, nawet co godzinę. Dawnym sposobem było umieszczenie daty w polu pkgver, które, jeśli oprogramowanie nie zostało zaktualizowane, makepkg nadal je przebudowuje, myśląc, że wersja uległa zmianie. Oto kilka przydatnych komend: git describe, hg identify -ni, itd. Przetestuj je przed przesłaniem PKGBUILD, ponieważ awaria funkcji pkgver() może zatrzymać kompilację w jej śladach.

Note: pkgver nie może zawierać spacji ani myślników (-). Użycie 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 pkg , w którym instaluje oprogramowanie. Pozwala to makepkg na pakowanie plików bez konieczności przesiewania systemu plików.

Pierwszym krokiem w funkcji build() jest przejście do katalogu utworzonego przez dekompresję archiwum źródłowego. makepkg zmieni bieżący katalog na $srcdir przed wykonaniem funkcji build(). Dlatego w większości przypadków, jak zasugerowano w /usr/share/pacman/PKGBUILD.proto, pierwsze polecenie będzie wyglądać tak:

cd "$pkgname-$pkgver"

Teraz musisz podać te same polecenia, które były używane podczas ręcznego kompilowania oprogramowania. Funkcja build() w istocie automatyzuje wszystko, co zrobiłeś ręcznie i kompiluje oprogramowanie w środowisku kompilacji fakeroot. Jeśli oprogramowanie, które pakujesz, używa skryptu configure, dobrze jest użyć --prefix=/usr podczas budowania pakietów dla pacmana. Wiele programów instaluje pliki względem katalogu /usr/local, które powinny być wykonywane tylko wtedy, gdy budujesz ręcznie ze źródeł. Wszystkie pakiety Arch Linux powinny korzystać z katalogu /usr. Jak widać w pliku /usr/share/pacman/PKGBUILD.proto, kolejne dwa wiersze często wyglądają tak:

./configure --prefix=/usr
make

Note: Jeśli twoje oprogramowanie nie potrzebuje niczego budować, nie używaj funkcji build(). Funkcja build() nie jest wymagana, ale funkcja package() jest.

check()

Miejsce na połączenia, aby wykonać make check i podobne procedury testowe. Zalecane jest użycie funkcji check(), ponieważ pomaga upewnić się, że oprogramowanie zostało poprawnie zbudowane i działa poprawnie z zależnościami.

Użytkownicy, którzy tego nie potrzebują (i czasami opiekunowie, którzy nie mogą naprawić pakietu do przekazania) mogą wyłączyć to 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, w którym makepkg może je pobrać, aby utworzyć pakiet. 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 umieszczać pliki w katalogu głównym systemu plików, powinieneś zainstalować je w katalogu pkg w tej samej strukturze katalogów. Na przykład, jeśli chcesz zainstalować plik w katalogu /usr/bin, zamiast tego należy go umieścić pod $pkgdir/usr/bin. Bardzo niewiele procedur instalacyjnych wymaga ręcznego kopiowania dziesiątek plików. Zamiast tego, w przypadku większości oprogramowania, wywołanie make install spowoduje to. Ostatnia linia powinna wyglądać następująco w celu poprawnej instalacji oprogramowania w katalogu pkg:

make DESTDIR="$pkgdir/" install

Note: Czasem zdarza się, że DESTDIR nie jest używany w Makefile; może być konieczne użycie prefix. Jeśli pakiet jest zbudowany z autoconf / automake, użyj DESTDIR; to właśnie jest udokumentowane w podręcznikach. Jeśli DESTDIR nie działa, spróbuj zbudować z make prefix="$pkgdir/usr/" install. Jeśli to nie zadziała, będziesz musiał zajrzeć dalej do poleceń instalacji, które są wykonywane przez "make <...> install".

makepkg --repackage uruchamia tylko funkcję package(), więc tworzy pakiet bez budynku. To może zaoszczędzić czas, np. jeśli zmieniłeś tylko zmienną depends pakietu.

Testowanie PKGBUILD i pakietu

Podczas pisania funkcji 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 Przy poprawnie sformatowanym pliku PKGBUILD, makepkg stworzy pakiet; z uszkodzony lub niedokończony PKGBUILD, spowoduje to błąd.

Jeśli makepkg zakończy się pomyślnie, umieści plik o nazwie pkgname-pkgver.pkg.tar.xz w twoim katalogu roboczym. Ten pakiet można zainstalować za pomocą komendy pacman -U. Jednak tylko dlatego, że plik pakietu został zbudowany, nie oznacza, że jest w pełni funkcjonalny. Może zawierać tylko katalog i żadnych plików, jeśli na przykład prefiks został określony nieprawidłowo. Możesz użyć funkcji zapytań pacmana do wyświetlenia listy plików zawartych w pakiecie i zależności, jakich wymaga, odpowiednio, pacman -Qlp [package file] i {ic|pacman -Qip [package file]}}.

Jeśli paczka wygląda na zdrową, to już koniec! Jeśli jednak planujesz zwolnienie pliku PKGBUILD, konieczne jest sprawdzenie i sprawdzenie zawartości depends.

Upewnij się także, że pliki binarne pakietów działają bezbłędnie! Denerwujące jest wydawanie pakietu zawierającego wszystkie niezbędne pliki, ale zawiesza się z powodu jakiejś niejasnej opcji konfiguracji, która nie działa dobrze z resztą systemu. Jeśli jednak zamierzasz kompilować pakiety tylko dla własnego systemu, nie musisz się martwić o ten krok zapewnienia jakości, bo przecież jesteś jedyną osobą cierpiącą na błędy.

Sprawdzanie poprawności pakietu

Po przetestowaniu funkcjonalności pakietu sprawdź, czy nie występują błędy przy użyciu namcap:

$ namcap PKGBUILD
$ namcap <package file name>.pkg.tar.xz

Namcap będzie:

1. Sprawdź zawartość PKGBUILD pod kątem typowych błędów i hierarchii 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łasza, które pakiety z wymaganymi bibliotekami współdzielonymi są niedostępne depends i które można pominąć jako zależności przechodnie
3. Heurystycznie szukaj brakujących i nadmiarowych zależności

i wiele więcej. Przyzwyczaj się do sprawdzania pakietów za pomocą namcap, aby uniknąć konieczności naprawiania najprostszych błędów po przesłaniu pakietu.

Przesyłanie pakietów do AUR

Proszę przeczytaj AUR User Guidelines#Submitting packages dla szczegółowego opisu procesu składania.

Podsumowanie

1. Pobierz archiwum źródłowe oprogramowania do pakietu.
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 jest poprawnie zbudowany.
6. Jeśli nie, powtórz dwa ostatnie kroki.

Ostrzeżenia

• Before you can automate the package building process, you should have done it manually at least once unless you know exactly what you are doing in advance, in which case you would not be reading this in the first place. Unfortunately, although a good bunch of program authors stick to the 3-step build cycle of "./configure; make; make install", this is not always the case, and things can get real ugly if you have to apply patches to make everything work at all. Rule of thumb: If you cannot get the program to compile from the source tarball, and make it install itself to a defined, temporary subdirectory, you do not even need to try packaging it. There is not any magic pixie dust in makepkg that makes source problems go away.
• In a few cases, the packages are not even available as source and you have to use something like sh installer.run to get it to work. You will have to do quite a bit of research (read READMEs, INSTALL instructions, man pages, perhaps ebuilds from Gentoo or other package installers, possibly even the MAKEFILEs or source code) to get it working. In some really bad cases, you have to edit the source files to get it to work at all. However, makepkg needs to be completely autonomous, with no user input. Therefore if you need to edit the makefiles, you may have to bundle a custom patch with the PKGBUILD and install it from inside the prepare() function, or you might have to issue some sed commands from inside the prepare() function.

PKGBUILD generators

PKGBUILDs for some packages can be generated automatically.

Note: Users are still responsible for ensuring that the package meets the high quality standards before submitting the generated files to the AUR.

• Go: go-makepkg
• Haskell: cblrepo
• Python: pipman-git^AUR, pip2arch-git^AUR, python-pypi2pkgbuild^AUR
• Ruby: gem2arch^AUR, pacgem^AUR

See also

• How to correctly create a patch file.
• Arch Linux Classroom IRC Logs of classes about creating PKGBUILDs.
• Fakeroot approach for package installation