Korzystanie z Devtools na Arch Linux

• Kompilowanie za pomocą Devtools
• Pliki konfiguracyjne Devtools
• Lokalne repozytorium
• Szybszy pakiet

Pakiet Devtools został pierwotnie stworzony dla Zaufanych użytkowników do prawidłowego tworzenia pakietów dla oficjalnych repozytoriów. Jednak może być również używany przez zwykłych użytkowników do budowania pakietów AUR, a nawet zmodyfikowanych oficjalnych pakietów.

Zapoznaj się z tym przewodnikiem, aby zrozumieć i ogólnie korzystać z AUR, w tym uzyskać PKGBUILD. Ten dokument pokazuje tylko kroki specyficzne dla Devtools, jeśli jest to metoda, którą wybrałeś do skompilowania pakietu.

Devtools utrzymuje osobną czystą instalację Arch, umieszczoną w /var/lib/archbuild/<TARGET>/root, która zawiera tylko grupy pakietów basei base-devel. Jeśli ta czysta instalacja nie istnieje, automatycznie ją tworzy. Jeśli istnieje, automatycznie aktualizuje zawarte w nim pakiety. Kiedy Devtools jest używane do zbudowania pakietu, zaczyna się od kopii tej czystej instalacji, instaluje wymagane pakiety tylko w kopii, kopiuje do niej kod źródłowy, wykonuje kompilację i pakowanie w nim, a jedynie kopiuje wynikowy pakiet, w identycznej formie jak w oficjalnych repozytoriach.

Devtools mają zalety w porównaniu do makepkgbezpośredniego uruchamiania . Jedną z zalet jest to, że base-develi inne pakiety niezbędne do kompilacji, ale nie uruchomienia, tworzony pakiet nigdy nie kończy się w głównym systemie. To mniej pakietów, które trzeba okresowo aktualizować, i masz obawy. Chociaż jest to przede wszystkim korzyść dla opiekunów pakietów Arch, proces ten łatwo ujawnia się, gdy błąd PKGBUILDjest niepoprawny, na przykład w przypadku braku zależności na liście, że opiekun już zainstalował się w swoim głównym systemie. Możesz także użyć maszyny, która szybciej buduje pakiety, i skopiować wynikowy pakiet na wolniejszą maszynę, która go uruchomi, bez zanieczyszczania instalacji maszyny budowlanej.

Główną wadą jest to, że czysty root jest zawsze tam, zajmuje około 800 MB, a zwykle jedna kopia zajmuje więcej miejsca. Uwaga: jeśli /var/lib/archbuild/używa Btrfs, kopia czystego katalogu głównego zaczyna się jako migawka Btrfs, więc pliki te nie zajmują podwójnej przestrzeni. Czysty katalog główny jest zawsze tam przechowywany, aby uniknąć ponownej instalacji przy każdym tworzeniu pakietu.

Kompilowanie za pomocą Devtools

Zainstaluj Devtools:

# pacman -S devtools

Aby zbudować pakiet, Devtools zawiera archbuild, ale nie uruchamiasz go bezpośrednio. Zawiera także dowiązania symboliczne {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-build. Dowiązanie symboliczne jest używane do uruchomienia, zostanie sprawdzone przez archbuild, aby określić, który cel ma być używany. Można go uruchomić, aby użyć tych niestabilnych / tymczasowych / testowych repozytoriów, które mogą mieć nowsze wersje niż te, które zostały wydane w oficjalnych repozytoriach. Aby użyć oficjalnych repozytoriów dla pakietów innych niż AUR, w katalogu z PKGBUILD, na przykład w katalogu utworzonym przez git clone, uruchom następujące polecenie:

$ extra-x86_64-build

Uwaga: reszta tego przewodnika będzie po prostu odwoływać się extra-x86_64-build.

Po zakończeniu działania zostaną wyświetlone następujące wyniki:

• /var/lib/archbuild/extra-x86_64/root- Czysty chroot , który jest aktualną instalacją z tylko grupami pakietów basei base-devel.
• /var/lib/archbuild/extra-x86_64/<USERNAME>- Będzie zawierać chroot kompilacji . Jest to kopia czystego chroota z wszelkimi zależnościami wymaganymi do zbudowania lub uruchomienia budowanego pakietu, a także jego kod źródłowy, wyniki kompilacji i pakiet.
• Katalog, w którym się znajdziesz, będzie zawierał pakiet i pliki dziennika kompilacji, a także każdy pobrany kod źródłowy.

Na końcu możesz zauważyć „ Checking PKGBUILD” i „ Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz”. Wszystkie wiersze po nich są wypisywane namcap, co automatycznie wyszukuje problemy, takie jak zniekształcone PKGBUILDpliki, uwzględnione zależności, których pakiet nie wydaje się używać, zależności, których nie uwzględniono w pakiecie, i wydaje się, że więcej. Często generowane są fałszywe alarmy namcap, ale jest to świetne narzędzie do dawania rzeczy do zbadania. Jeśli twój pakiet działa poprawnie, nie jest dobrym pomysłem powiadomienie opiekuna o namcapwyjściu, chyba że go sprawdziłeś i zweryfikowałeś, że należy wprowadzić zmianę.

Możesz użyć pacmando zainstalowania pakietu, który zainstaluje wszelkie zależności wymagane do uruchomienia pakietu, o ile znajdują się one w oficjalnych repozytoriach lub lokalnym repozytorium.

Użyj lokalnego repozytorium, jak wyjaśniono tutaj , lub zainstaluj plik bezpośrednio:

# pacman -U <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz

Jeśli chcesz extra-x86_64-buildponownie uruchomić , teraz lub w dowolnym późniejszym czasie z tym lub innym pakietem, zaktualizuje on czystego chroota, jeśli to konieczne, usunie go i uczyni z niego nową kopię czystego chroota, i wykonasz ten sam proces. Jeśli twój katalog nadal ma pobrany kod źródłowy z ostatniego razu, użyje go. Jeśli pakiet jest rozwojowym pakietem AUR, spowoduje pobranie nowych zmian zamiast ponownego klonowania.

Wewnętrznie extra-x86_64-builddziała makechrootpkg, który wewnętrznie wywołuje makepkg. Dostępne extra-x86_64-buildsą następujące opcje :

• -c: Wyczyść chrooty, usuwając i ponownie tworząc cały /var/lib/archbuild/extra-x86_64/katalog, w tym czysty chroot i wszystkie katalogi budowania chroot. Jest to rzadko potrzebne, tylko jeśli czysty chroot zostanie uszkodzony lub jeśli Devtools zostanie zaktualizowane w sposób, który narusza wsteczną kompatybilność.
• -r <dir>: Użyj innego katalogu niż /var/lib/archbuild/extra-x86_64/do przechowywania chroots.

Wszelkie argumenty do extra-x86_64-buildpo --są przekazywane do makechrootpkg, gdy używa go wewnętrznie. Kilka argumentów jest zawsze automatycznie przekazywanych od extra-x86_64-builddo makechrootpkg. Te automatyczne argumenty są -r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -n. Mówią, makechrootpkgaby usunąć chroota kompilacji i uczynić go świeżą kopią czystego chroota i uruchomić namcapna pakiecie, jeśli pomyślnie się skompiluje. Często stosowaną opcją, którą można przekazać, makechrootpkgjest -l <copy name>. Jest to nazwa katalogu <USERNAME>, która ma dać chroot kompilacji zamiast , co jest przydatne do utrzymywania wielu kopii lub kompilacji wielu pakietów jednocześnie.

Wszelkie argumenty do makechrootpkgpo --są przekazywane makepkg, gdy wewnętrznie używa go do zbudowania pakietu. Przy pierwszym makepkguruchomieniu makechrootpkgwykonuje się to z własnymi niezmiennymi opcjami, aby w razie potrzeby pobrać pliki źródłowe i wykonać kontrole integralności; dlatego nic nie może zostać przekazane w tym przebiegu. Uruchamia makepkgsię po raz drugi, aby skompilować pakiet, i zawsze automatycznie przekazuje makepkgargumenty, o --syncdeps --noconfirm --log --holdver --skipintegktórych mówi makepkgchroot w chroot kompilacji, aby automatycznie instalował brakujące zależności wymagane do zbudowania i używania pakietu, aby nie pytać o potwierdzenie pacman, zalogować proces kompilacji do tekstu plików oprócz stdout, nie aktualizuj kodu źródłowego, jeśli jest w systemie kontroli wersji i nie wykonuj kontroli weryfikacji pliku źródłowego.

Możesz połączyć je razem, używając następującego formularza:

$ extra-x86_64-build <DEVTOOLS-OPTIONS> -- <MAKECHROOTPKG-OPTIONS> -- <MAKEPKG-OPTIONS>

Zauważ, że /var/lib/archbuildmożna to traktować jak katalog tymczasowy. Jeśli masz wiele dysków twardych Vultr, warto zamontować tutaj system plików RAID0 (pasek). Jeśli masz dużo pamięci RAM, możesz także zamontować system plików z pamięcią RAM, taki jak tmpfs. Po zbudowaniu pakiet jest kopiowany do katalogu, z którego uruchomiono, extra-x86_64-builda jeśli chcesz, w tym momencie możesz go usunąć /var/lib/archbuild. Następny bieg byłby wolniejszy, ponieważ musiałby utworzyć nowy czysty root. Alternatywnie, możesz usunąć, /var/lib/archbuild/<USERNAME>aby odzyskać dodatkowe miejsce z chroota kompilacji, zanim zostanie ono automatycznie usunięte przy następnym uruchomieniu Devtools. Tak więc, nawet jeśli zamontowany tutaj system plików RAID0 nie powiedzie się, najbardziej stracisz kompilację w toku.

Pliki konfiguracyjne Devtools

Pliki konfiguracyjne Devtools wymagają uwagi. Znajdują się w /usr/share/devtools/, takich jak makepkg-x86_64.confi pacman-extra.conf:

• W przypadku /etcplików takich jak makepkg.confi pacman.confmożesz bezpiecznie edytować je w miejscu, a po uaktualnieniu pakietu nie zastąpi on twoich zmian. Zamiast tego zapisze nowe pliki konfiguracyjne (jeśli zmieniły się w stosunku do poprzedniej wersji) kończące się na .pacnew. Jednak pliki konfiguracyjne Devtools /usr/share/nie są przeznaczone do edycji przez użytkownika, więc po aktualizacji Devtools całkowicie nadpisze twoje zmiany w tych plikach bez powiadamiania cię. Zmiana tego zachowania została zaproponowana i odrzucona, ponieważ pomaga to zapewnić przesyłanie pakietów do oficjalnych repozytoriów z tymi samymi ustawieniami kompilacji.
• Wartość dla MAKEFLAGS, PACKAGERi {SRC,SRCPKG,PKG,LOG}DESTpochodzi /etc/makepkg.confraczej od niż /usr/share/devtools/makepkg-x86_64.conf.

Lokalne repozytorium

Jeśli pacmanbudujesz pakiety, które są zależne od innych zbudowanych przez siebie pakietów, musisz użyć lokalnego repozytorium, aby po uruchomieniu w chroot kompilacji znalazł zależności.

Aby skonfigurować lokalne repozytorium, zapoznaj się z sekcją „Lokalne repozytorium” tego podręcznika .

Utwórz niestandardowy cel:

# ln -s archbuild /usr/bin/custom-x86_64-build
# cp /usr/share/devtools/pacman-{extra,custom}.conf

Edytuj /usr/share/devtools/pacman-custom.confi dodaj na końcu:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

Edytuj /etc/pacman.confi dodaj następujące elementy. Wymusza to podłączenie katalogu do chroota:

CacheDir    = /var/cache/pacman/pkg/ /archLocalRepo/

Teraz zamiast używać extra-x86_64-buildużyj tego:

$ custom-x86_64-build

Jeśli zawsze chcesz używać niestandardowego celu, możesz usunąć /var/lib/archbuild/extra-x86_64-build/katalog, jeśli istnieje, ponieważ chroots będą teraz w /var/lib/archbuild/custom-x86_64-build/.

Szybszy pakiet

Uwaga: włączenie pakowania w /usr/share/devtoolswątki obejmuje edycję plików konfiguracyjnych, które nie są oficjalnie obsługiwane, więc musisz wprowadzić tę zmianę przy każdym uaktualnieniu Devtools.

Devtools łączy cały pakiet w format archiwalny. Domyślnie .tar.xzużywa pojedynczego wątku do xzkompresji.

W systemach wieloprocesorowych możesz zezwolić xzna użycie wielu wątków poprzez edycję /usr/share/devtools/makepkg-x86_64.confi zmienić następujący wiersz:

COMPRESSXZ=(xz -c -z -)

Aby zezwolić na tyle wątków, ile masz wirtualnych rdzeni:

COMPRESSXZ=(xz -c -z - --threads=0)

Aby zezwolić na używanie wielu wirtualnych rdzeni, ale nie wszystkich, w celu zmniejszenia wpływu na ogólną wydajność systemu, dodaj konkretną liczbę:

COMPRESSXZ=(xz -c -z - --threads=21)

Określenie większej liczby wątków niż liczba wirtualnych rdzeni spowoduje zmniejszenie wydajności.

Jeśli nie przeszkadza ci to, że plik pakietu jest (potencjalnie znacznie) większy, wyłącz kompresję poprzez edycję /usr/share/devtools/makepkg-x86_64.confi zmień następujący wiersz:

PKGEXT='.pkg.tar.xz'

Zmień go, aby wyglądał następująco:

PKGEXT='.pkg.tar'