Budowanie pakietów na Arch Linux (w tym AUR)

• PKGBUILD
• Uzyskanie PKGBUILD / ETC
• Aktualizacja PKGBUILD / ETC
• Kompilacja
• Lokalne repozytorium
• Kompiluj szybciej
• Błąd podpisu PGP
• Pakiety rozwojowe AUR
• Nieaktualne pakiety

W Arch Linux oficjalne repozytoria to: core, extra i community. Te pakiety są już skompilowane i są instalowane pacman. W większości użytkownicy ogólni mogą zignorować to, że te 3 oficjalne repozytoria są oddzielne. Rdzeń zawiera najbardziej krytyczne pakiety, takie jak jądro, proces uruchamiania, sieć, zarządzanie pakietami, openssh i tak dalej. Ma również surowsze wymagania dotyczące dokładniejszych testów przed wydaniem nowych wersji. Extra zawiera inne popularne pakiety, które nie są tak krytyczne, takie jak serwer X, menedżery okien lub przeglądarki internetowe. Społeczność zawiera mniej popularne pakiety. Tylko zaufani użytkownicy (około 60 aktywnych użytkowników, na których głosowali inni zaufani użytkownicy) mają dostęp do wprowadzania zmian w oficjalnych repozytoriach.

W 2019 r. W oficjalnych repozytoriach znajduje się około 11 000 paczek na stronie https://www.archlinux.org/packages . Istnieje jednak wiele innych programów dostępnych w systemie Linux. AUR (Arch Linux User Repository) istnieje, więc każdy użytkownik Arch może dodać nowy program i zostać jego opiekunem lub przyjąć „osierocony” pakiet bez bieżącego opiekuna. W AUR znajduje się około 55 000 pakietów na stronie https://aur.archlinux.org/ .

Istnieją 3 krytyczne różnice z AUR:

1. Ponownie, te pakiety mogą być wytwarzane przez dowolnego użytkownika, nawet zupełnie nowego.
2. AUR zawiera tylko PKGBUILDskrypt powłoki, który automatycznie tworzy pakiet, a nie skompilowane pliki binarne. (Czasami zawiera także małe łatki tekstowe lub instaluje / aktualizuje / odinstalowuje skrypty powłoki). Wykonało to ogromną pracę, umożliwiając każdemu użytkownikowi udział, jednocześnie zmniejszając szansę na rozpowszechnienie złośliwego kodu. Społeczność Arch jest nadal bardzo pomocna w przypadku problemów z pakietami AUR, ale należy zauważyć, że korzystanie z nich odbywa się na własne ryzyko. Ponieważ wszystko, co zapewnia PKGBUILD, to w ostatecznym rozrachunku Twoim obowiązkiem jest sprawdzenie, którego PKGBUILDbędziesz używać. (Oczywiście wielu użytkowników tego nie robi i po prostu polega na innych).
3. Ponieważ pacmannie wchodzi on w interakcje bezpośrednio z AUR, Twoim obowiązkiem jest aktualizowanie pakietów AUR. Podczas okresowego uaktualniania całego systemu pacmannie będzie on automatycznie pobierał aktualizacji PKGBUILDplików AUR , kompilował je i instalował za Ciebie.

Chociaż ten artykuł koncentruje się na tworzeniu pakietów z AUR, te same techniki mogą być użyte do samodzielnego tworzenia pakietów z oficjalnych repozytoriów.

PKGBUILD

W porównaniu do .specpliku używanego przez wiele innych dystrybucji, a PKGBUILDjest krótkim i prostym skryptem powłoki. Chociaż niektóre pakiety są bardziej złożone, mogą być po prostu podobne do następujących:

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc='DESCRIPTION'
url=http://example.com/
arch=('x86_64')
license=('GPL2')
source=(http://example.com/downloads/${pkgname}-${pkgver}.tar.gz)
sha256sums=('f0a90db8694fb34685ecd645d97d728b880a6c15c95e7d0700596028bd8bc0f9')

build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure
   make
}

package() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   make install
}

Ten dokument dotyczy:

• PKGNAME: Nazwa pakietu
• PKGVER: Wersja pakietu (prawie zawsze pasująca do numeru wersji nadrzędnej)
• PKGREL: Arch „wersja” PKGBUILDfor dla określonego PKGVER(zwykle 1, ale zwiększana, jeśli trzeba wprowadzić zmiany PKGBUILDmiędzy wydaniami poprzedzającymi)
• ARCH: Architektury, na których można zbudować pakiet (nieco starsze, ponieważ oficjalne repozytoria Arch Linux obsługują tylko „x86_64” (procesory 64-bitowe), ale pakiety AUR nadal mogą obsługiwać „i686” (procesory 32-bitowe) lub „dowolny” określenie architektury nie ma znaczenia)
• PKGBUILD/ETC: Wszelkie pliki faktycznie w repozytorium AUR; te PKGBUILDi wszelkie inne łaty mały tekst lub instalacji / aktualizacji / usuwania skryptów powłoki. Nie zawiera plików nadrzędnych w sourcetablicy.

Chociaż AUR okazało się niezwykle godne zaufania, warto przyjrzeć się PKGBUILD/ETCtemu, aby upewnić się, że pobiera źródło z miejsca, w którym chcesz zaufać; (na przykład oficjalna lokalizacja nadrzędna, która może pochodzić z github - ale nie tylko repozytorium github przypadkowej osoby, która nie jest powiązana z pakietem nadrzędnym); i że PKGBUILD/ETCnie zawiera podejrzanego kodu.

Uzyskiwanie PKGBUILD/ETC

Z AUR

Jeśli oficjalne repozytoria nie zawierają pakietu, który chcesz zainstalować, wyszukaj go na https://aur.archlinux.org/ . Mamy nadzieję, że okaże się, że to, czego szukasz, jest aktualne i utrzymywane.

Najlepszym sposobem na uzyskanie PKGBUILD/ETCz AUR jest jego sklonowanie git.

Zainstaluj git, jeśli jeszcze nie jest:

# pacman -S git

Użyj „Git Clone URL” pokazanego na stronie AUR dla tego pakietu:

$ git clone https://aur.archlinux.org/fslint.git

Wejdź do katalogu i sprawdź jego zawartość. (Wszystko tutaj wymienione, z wyjątkiem . .. .gitjest PKGBUILD/ETC):

$ cd <PKGNAME>
$ ls -a
.  ..  .git  PKGBUILD  .SRCINFO

Jeśli przyjrzysz się temu PKGBUILD, zobaczysz, że używa oficjalnego kodu źródłowego i wykonuje typowe kroki w celu zbudowania pakietu, więc wydaje się to godne zaufania. Po .SRCINFOprostu zawiera informacje pokazane na stronie internetowej o pakiecie, więc nie jest to niepokojące. Jeśli są tu jakieś inne pliki, nie są one (bezpośrednio) dostarczane przez nadrzędne, więc pliki i sposób ich użycia PKGBUILDpowinny zostać zbadane, aby upewnić się, że nie zawierają niczego podejrzanego.

Z oficjalnych repozytoriów

Chociaż jest to wymagane znacznie rzadziej, możesz zbudować pakiet już w oficjalnych repozytoriach, aby dołączyć nową łatkę, zbudować nowszą wersję itp.

Uzyskaj PKGBUILD/ETCz podstawowego i dodatkowych repozytoriów:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/packages.git "<PKGNAME>"

Z repozytorium społeczności:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/community.git "<PKGNAME>"

Aktualizacja PKGBUILD/ETC

Jeśli uaktualnienie PKGBUILD/ETCzostanie wydane, możesz wrócić do tego katalogu utworzonego za pomocą git clonei zaktualizować je:

$ git pull

Następnie ponownie skompiluj i zaktualizuj pakiet, korzystając z wybranej metody, poniżej.

Kompilacja

Istnieje wiele sposobów kompilacji pakietów. Ostatecznie wszystko wykorzystuje makepkg. Istnieją 2 oficjalnie obsługiwane sposoby:

• Aby użyć bezpośrednio makepkg, zobacz https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Aby użyć pośrednio makepkgw czystości chroot, zobacz https://www.vultr.com/docs/using-devtools-on-arch-linux .

Istnieje wiele programów AUR pomocnik, (jak makepkgowijki), które nie są oficjalnie wspierane przez Arch, takie jak aurutils, yayi ostatnio przerwane aurmani yaourt. Nawet jeśli korzystasz z jednego z tych innych programów pomocniczych, Zdecydowanie zalecamy zapoznanie się z oficjalnie obsługiwanymi sposobami zwiększenia skuteczności, gdy coś pójdzie nie tak.

Pozostała część tego dokumentu będzie YOUR BUILDERoznaczać dowolną wybraną metodę.

Lokalne repozytorium

Możesz skonfigurować lokalne repozytorium, aby było centralną lokalizacją dla wszystkich budowanych pakietów.

Umieść lokalne repozytorium w dowolnym miejscu:

# mkdir /archLocalRepo

Uruchom YOUR BUILDERbez żadnych opcji automatycznej instalacji i skopiuj pakiet do lokalnego repozytorium.

# cp <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz /archLocalRepo

Dodaj nowy pakiet do indeksu repozytorium:

# repo-add /archLocalRepo/archLocalRepo.db.tar.gz /archLocalRepo/<PACKAGE-FILE-NAME>

Aby usunąć pakiet z indeksu repozytorium i samego pliku pakietu:

# repo-remove /archLocalRepo/archLocalRepo.db.tar.gz <PKGNAME>
# rm /archLocalRepo/<PACKAGE-FILE-NAME>

Jeśli musisz zastąpić istniejący plik pakietu, musisz osobno usunąć zastępowany plik, a następnie dodać nowy. Nie można po prostu skopiować nowego pliku na stary.

Skonfiguruj pacmankorzystanie z lokalnego repozytorium, edytując /etc/pacman.confi dodając następujące elementy na końcu:

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

Musisz pacmanodświeżyć swoją wiedzę o repozytorium (w tym lokalnym) baz danych; aby zobaczyć dodane do niego pakiety:

# pacman -Sy

Następnie możesz zainstalować pakiet, nie inaczej niż w oficjalnym repozytorium:

# pacman -S <PKGNAME>

Uwaga: jeśli pakiet jest jedynie zależnością innego pakietu, który zamierzasz zainstalować, nie musisz go instalować bezpośrednio. Po zainstalowaniu tego drugiego pakietu pacmanautomatycznie znajdzie i zainstaluje pakiety zależności w lokalnym repozytorium.

Kompiluj szybciej

Domyślnie YOUR BUILDERkompiluje przy użyciu jednego wątku. W systemach wieloprocesorowych możesz zezwolić na używanie wielu wątków tam, gdzie to możliwe. System kompilacji będzie kompilował części kodu źródłowego równolegle, gdy będzie to możliwe. Czasami części kodu wymagają innych części, z którymi wchodzi w interakcję, aby zostały już skompilowane, więc nie zawsze zobaczysz tyle używanych wątków, ile jest dozwolonych. Edit /etc/makepkg.conf.

Aby zezwolić na używanie tylu wątków, ile masz wirtualnych rdzeni, dodaj następujące elementy:

MAKEFLAGS="-j$(nproc)"

Uwaga: To spowoduje uruchomienie polecenia za nprockażdym razem, więc zawsze będzie używał bieżącej liczby rdzeni, w przypadku uaktualnienia serwera Vultr

Aby umożliwić korzystanie z wielu wirtualnych rdzeni, ale nie wszystkich, na przykład w celu zmniejszenia wpływu na ogólną wydajność systemu, dodaj określoną liczbę. Na przykład, jeśli masz 24 rdzenie, możesz zezwolić na użycie 21:

MAKEFLAGS="-j21"

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

Jest to dość rzadkie, ale systemy kompilacji niektórych pakietów mają problemy z kompilacją równoległą, z powodu nieprawidłowego zdefiniowania zależności między częściami kodu. Zazwyczaj PKGBUILDpliki tych pakietów obsłużą to za Ciebie, wywołując make -j1, co zastępuje ustawioną wartość domyślną. Jeśli potrzebuje tego i brakuje go, zgłoś to do opiekuna pakietu Arch.

Błąd podpisu PGP

Tablica PKGBUILDźródłowa może zawierać .asclub .sigpliki. Są one często uwzględniane przy użyciu rozszerzenia nawiasów klamrowych, więc można łatwo przeoczyć:

source=("http://example.com/downloads/${pkgname}-${pkgver}.tar.gz{,.sig}")

Jeśli jeden z tych formatów plików sygnatur znajduje się w tablicy źródłowej, YOUR BUILDERautomatycznie próbuje zweryfikować podpis archiwum źródłowego. Klucz PGP podpisu musi znajdować się w breloku użytkownika; w przeciwnym razie przerwie się z błędem:

==> Verifying source file signatures with gpg...
    <SOURCE-FILE> ... FAILED (unknown public key 1234567890ABCDEF)
==> ERROR: One or more PGP signatures could not be verified!

Ważne jest, aby zrozumieć, że klucz GPG można wyświetlić na kilka sposobów. Jego odcisk palca to 40 znaków szesnastkowych i zawsze powinieneś go używać. Długi klucz to ostatnie 16 cyfr, a krótki klucz to ostatnie 8 cyfr. Chociaż krótszy jest wygodny, pozwala na duplikaty, co unieważnia całe rozumowanie stojące za weryfikacją podpisów. Co gorsza, znani są z tego, że atakujący generują fałszywe klucze, które pasują do kluczy o mniejszej długości dla programistów o wysokich profilach.

Uzyskaj i zweryfikuj klucz linii papilarnych PGP

Jeśli nie próbowałeś jeszcze zbudować pakietu, pobierz źródła, które będą zawierać plik podpisu: (Jeśli próbowałeś zbudować, już tam będzie)

$ makepkg --nobuild --noextract

Aby uzyskać pełny odcisk palca:

$ gpg <ASC-OR-SIG-FILENAME>
...
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
...

Najlepiej byłoby zweryfikować ten odcisk palca z góry. Aby być bezpiecznym, upstream powinien przekazać klucze swoich opiekunów gdzieś na swojej stronie internetowej lub w źródle. Samo wyszukiwanie klucza na serwerze kluczy tak naprawdę nic nie robi. Osoba atakująca może łatwo przesłać fałszywy klucz, ponieważ serwery kluczy nie weryfikują autentyczności. Klucze mogą być podpisywane innymi kluczami, więc jeśli masz już klucz, któremu ufasz, powinieneś być całkiem bezpieczny, ufając wszystkim podpisanym kluczom.

Może to być dość pracochłonne, szczególnie gdy upstream nie publikuje swojego odcisku palca ani nie umieszcza go w łatwym do znalezienia miejscu. PKGBUILDBędzie zawierać validpgpkeystablicę, którą wprowadza przez opiekuna Arch. Jeśli pakiet jest oficjalnym repozytorium, oznacza to, że zaufany użytkownik go tam umieścił i powinieneś być całkiem bezpieczny, aby zaufać tylko cokolwiek z tablicy. Jeśli pakiet znajduje się w AUR, pamiętaj, że oznacza to po prostu, że inny użytkownik Arch go tam umieścił. Jeśli martwisz się zaufaniem, zawsze możesz spojrzeć na użytkownika, aby zobaczyć, co zrobił w przeszłości z Arch.

Dodaj klucz PGP do breloka

Aby dodać odcisk palca do breloka do kluczy:

$ gpg --recv-keys <FINGERPRINT>

Możesz teraz uruchomić YOUR BUILDER, a zaufa odcisk palca.

Pakiety rozwojowe AUR

Pakiety AUR o nazwach kończących -git, -svn, -bzrlub -hgw wersjach rozwojowych, które wykorzystują Upstream ostatnie systemu kontroli wersji popełnić zamiast upstream to najnowsza wersja. Na przykład-gitpakiet użyje najnowszego zatwierdzenia upstream w gałęzi master (lub równoważnej gałęzi). Jest to świetne do uruchamiania poprawek błędów upstream i nowych funkcji, które nie zostały jeszcze wydane, a także podczas pracy z upstream nad błędem, który zgłaszasz, w tym jeśli musisz sprawdzić, czy nie jest to błąd, który został naprawiony przez zatwierdzenie, którego jeszcze nie wydano. Pakiety te należy uznać za potencjalnie niestabilne. To powiedziawszy, niestety, czasami nie ma alternatywy, ponieważ niektórzy opiekunowie wyższego szczebla nigdy nie tagują wydań lub nie przesadzają zbyt długo między oznaczaniem wydań i oczekują, że wszyscy użyją swojego ostatniego zatwierdzenia. W zależności od pakietu możesz być pierwszą osobą, która spróbuje uruchomić to zatwierdzenie. W zależności od twórców oprogramowania, ich ostatnie zatwierdzenie może nawet nie zostać skompilowane,

Ważne jest, aby zrozumieć powszechny błąd. Nie oznaczaj pakietu rozwojowego AUR jako nieaktualnego, ponieważ zawiera on stary numer wersji! PKGBUILDPliki pakietów rozwojowych zawierają dodatkową funkcję pkgver(), która służy do automatycznego analizowania zaktualizowanego PKGVERkodu źródłowego. Typowym formatem -gitpakietu jest <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Pakiet może być wymieniony w AUR jako 5.0.0.r102.8d7b42ac21-1, ponieważ jest to, co PKGBUILDzawiera. Ale po utworzeniu pakietu YOUR BUILDERzostanie automatycznie zaktualizowany, PKGVERaby odzwierciedlić nowo pobrany kod źródłowy. W rzeczywistości, jeśli wydano wiele nowych wersji, ale nic się nie zmieniło w procesie kompilacji, takie PKGBUILDwyświetlanie starej wersji może zakończyć się budowaniem czegoś znacznie nowszego, na przykład9.1.2.r53.2c9a41b723-1. W przypadku tych pakietów wersja wymieniona na stronie jest po prostu najnowszą wersją w momencie, gdy administrator AUR musiał po raz ostatni zaktualizować PKGBUILD.

Opiekunowie AUR NIE powinni po prostu aktualizować, PKGVERaby odzwierciedlić nowe wersje. Powinny to zrobić tylko wtedy, gdy nowsze zatwierdzenia na wyższym poziomie faktycznie wymagają PKGBUILDzmiany.

Oflaguj pakiet rozwojowy AUR jako nieaktualny, jeśli wiesz, że coś jest nie tak. Oznacza to, że faktycznie próbowałeś go użyć i nie powiedzie się kompilacja lub parsowanie poprawnie sformatowanego nowego PKGVER. Czasami zdarzają się sytuacje, które zmuszają opiekuna AUR do aktualizacji PKGBUILD, np. Zmiany zależności upstream, zmiany configureopcji, nowe wersje GCC wychwytują błędy w kodzie źródłowym, których nie robiły poprzednie, zmiany lokalizacji repozytorium upstream lub deweloperzy upstream zmienią tam, gdzie ich typowa wersja jest w kodzie źródłowym, który łamiePKGVERfunkcja parsowania. Zrozum, że nawet jeśli kompilacja lub działanie nie powiedzie się, może to oznaczać, że opiekun AUR musi wprowadzić zmiany w procesie kompilacji, lub może to być problem z kodem źródłowym, za który opiekun AUR nie ponosi odpowiedzialności.

Nieaktualne pakiety

Przeczytaj raport „Pakiety rozwojowe AUR” powyżej, zanim zgłosisz pakiet jako nieaktualny!

Jeśli upstream opublikował nowszą wersję pakietu niezwiązanego z programowaniem niż w PKGBUILD, możesz kliknąć „Oflaguj pakiet nieaktualny” i wpisać wiadomość do opiekuna. Użyj https://packages.archlinux.org dla oficjalnych pakietów repozytorium i https://aur.archlinux.org dla pakietów AUR. Pomocną wiadomością może być nowy numer wersji i być może link do ogłoszenia o wydaniu lub kodu źródłowego. Funkcja oznaczania automatycznie wysyła wiadomość e-mail do opiekuna.

W przypadku pakietu AUR, jeśli nie otrzymano odpowiedzi po 2 tygodniach, możesz kliknąć „Prześlij żądanie” z typem „Orphan”, jeśli chcesz poprosić Zaufanego użytkownika o usunięcie bieżącego opiekuna i uczynienie pakietu osieroconym, jeśli opiekun nie odpowiada na żądanie osierocone. Zasadniczo ludzie składają wnioski osierocone tylko wtedy, gdy są w stanie i chcą przejąć pakiet, a najlepiej tylko wtedy, gdy mają już działający prąd PKGBUILD.

W międzyczasie często możesz samodzielnie zaktualizować przestarzały pakiet. Często wystarczy zmienić a PKGBUILD, aktualizując PKGVERdo nowego numeru wersji, a sumy wiarygodności są aktualizowane. Program updpkgsumsistnieje w pakiecie pacman-contrib, który automatycznie oblicza sumy i aktualizuje je PKGBUILDdla ciebie. Warto sprawdzić informacje o wydaniu wcześniejszego wydania, aby zobaczyć, czy wspominają, że wszystko musi się zmienić podczas procesu instalacji nowej wersji. Czasami zmiany poprzedzające wymagają więcej zmian lub remontów PKGBUILD/ETC. Często sourcetablica się PKGVERw nim osadza , więc często nawet nie wymaga aktualizacji.