Изграждане на пакети на Arch Linux (включително AUR)

В Arch Linux официалните хранилища са: core, extra и community. Тези пакети вече са компилирани и се инсталират чрез pacman. В по-голямата си част обикновените потребители могат да игнорират, че тези 3 официални хранилища са отделни. Core съдържа най-критичните пакети, като ядрото, процеса на зареждане, работа в мрежа, управление на пакети, openssh и т.н. Той също така има по-строги изисквания за по-задълбочено тестване преди пускането на нови версии. Extra съдържа други популярни пакети, които не са толкова критични, като X сървър, мениджъри на прозорци или уеб браузъри. Общността съдържа по-малко популярни пакети. Само доверени потребители (около 60 активни потребители, за които са гласували други доверени потребители) имат достъп да правят промени в официалните хранилища.

През 2019 г. има около 11 000 пакета в официалните хранилища на адрес https://www.archlinux.org/packages . Но има много други програми, налични в Linux. И така, AUR (Arch Linux User Repository) съществува, така че всеки потребител на Arch може да добави нова програма и да стане неин поддържащ или да приеме "осиротел" пакет без текущ поддържащ. Има около 55 000 пакета в AUR, на https://aur.archlinux.org/ .

Има 3 критични разлики с AUR:

1. Отново, тези пакети могат да бъдат произведени от всеки потребител, дори и от чисто нов.
2. AUR съдържа само a PKGBUILD, шел скрипт за автоматично създаване на пакета, а не компилирани двоични файлове. (Понякога съдържа и малки текстови корекции или скриптове за инсталиране/надграждане/деинсталиране на обвивката). Това свърши огромна работа, позволявайки на всеки потребител да допринесе, като същевременно намали шанса някой да може да разпространява злонамерен код. Общността на Arch все още е доста полезна по отношение на проблемите с пакетите AUR, но се отбелязва, че използването им е на ваш собствен риск. Тъй като всичко, което предоставя, е PKGBUILD, в крайна сметка ваша отговорност е да прегледате този, PKGBUILDкойто ще използвате. (Разбира се, много потребители не правят това и просто разчитат на други да следят.)
3. Тъй като pacmanне взаимодейства директно с AUR, ваша отговорност е да актуализирате пакетите AUR. Когато периодично надграждате цялата си система чрез pacman, тя няма да изтегля автоматично актуализации на AUR PKGBUILDфайлове, да ги компилира и да ги инсталира вместо вас.

Въпреки че тази статия се фокусира върху изграждането на пакети от AUR, същите техники могат да се използват за създаване на пакети от официалните хранилища сами.

PKGBUILD

В сравнение с .specфайл, който много други дистрибуции използват, a PKGBUILDе кратък и прост шел скрипт. Въпреки че някои пакети са по-сложни, те могат просто да бъдат подобни на следните:

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
}

Този документ се отнася до:

• PKGNAME: Името на пакет
• PKGVER: Версията на пакет (почти винаги съвпадаща с номера на версията нагоре по веригата)
• PKGREL: Arch "версията" на PKGBUILDза конкретна PKGVER(обикновено 1, но се увеличава, ако трябва да се направят промени в a PKGBUILDмежду изданията нагоре по веригата)
• ARCH: Архитектурите, върху които пакетът може да бъде изграден (донякъде наследени, тъй като официалните хранилища на Arch Linux поддържат само "x86_64" (64-битови процесори), но пакетите AUR все още могат да поддържат "i686" (32-битови процесори) или "всякакъв" да се обозначава архитектура е без значение)
• PKGBUILD/ETC: Всички файлове действително в хранилището на AUR; на PKGBUILD, както и всички други малки текстови кръпки или да инсталира / Надстройка / деинсталиране на шел скриптове. Не включва файлове нагоре по веригата в sourceмасива.

Въпреки че AUR се е доказал като изключително надежден, добре е да погледнете a, PKGBUILD/ETCза да сте сигурни, че получава източника от място, на което сте готови да се доверите; (например официално местоположение нагоре по веригата, което може да бъде от github - но не само от хранилището на github на случаен човек, което не е свързано с пакета нагоре по веригата); и че PKGBUILD/ETCне съдържа подозрителен код.

Получаване PKGBUILD/ETC

От AUR

Ако официалните хранилища не съдържат пакет, който искате да инсталирате, потърсете го на https://aur.archlinux.org/ . Надяваме се, че ще откриете, че това, което търсите, съществува, е актуално и поддържано.

Най-добрият начин да получите PKGBUILD/ETCот AUR е да го клонирате чрез git.

Инсталирайте git, ако все още не е:

# pacman -S git

Използвайте "Git Clone URL", показан на уебсайта на AUR за този пакет:

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

Влезте в директорията и вижте съдържанието й. (Всичко изброено тук, с изключение на . .. .gitе PKGBUILD/ETC):

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

Ако разгледате PKGBUILD, ще се надяваме, че ще видите, че използва официалния изходен код нагоре по веригата и изпълнява типични стъпки за изграждане на пакет, така че изглежда надежден. Най- .SRCINFOпросто съдържа информацията, показани на сайта на около пакета, така че не е тревожен. Ако тук има други файлове, те не са (директно) предоставени от upstream, така че файловете и как се използват в файла PKGBUILDтрябва да бъдат проучени, за да се уверите, че не съдържат нищо подозрително.

От официалните хранилища

Въпреки че се изисква много по-рядко, можете да създадете пакет вече в официалните хранилища, да включите нова корекция, да изградите по-нова версия и т.н.

Вземете PKGBUILD/ETCот ядрото и допълнителните хранилища:

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

От хранилището на общността:

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

Надграждане PKGBUILD/ETC

Ако PKGBUILD/ETCбъде пусната надстроена , можете да се върнете в тази директория, направена с помощта на git clone, и да ги актуализирате:

$ git pull

След това прекомпилирайте и надстройте пакета, като използвате метода по ваш избор, по-долу.

Компилиране

Има много начини за компилиране на пакети. В крайна сметка всичко използва makepkg. Има 2 официално поддържани начина:

• За директно използване makepkgвижте https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• За непряко използване makepkgв чист chroot, вижте https://www.vultr.com/docs/using-devtools-on-arch-linux .

Има много помощни програми за AUR (като makepkgобвивката), които не се поддържат официално от Arch, като aurutils, yay, и наскоро прекратените aurmanи yaourt. Дори ако използвате някоя от тези други помощни програми, силно се препоръчва да се запознаете с официално поддържаните начини за по-голяма ефективност, когато нещо се обърка.

Останалата част от този документ ще използва YOUR BUILDERза означаване на метода, който изберете.

Локално хранилище

Можете да настроите локално хранилище да бъде централно място за всички пакети, които създавате.

Поставете локалното хранилище, където искате:

# mkdir /archLocalRepo

Изпълнете YOUR BUILDERбез опции за автоматична инсталация и копирайте пакета във вашето локално хранилище.

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

Добавете новия пакет към индекса на хранилището:

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

За да премахнете пакет от индекса на хранилището и самия пакет файл:

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

Ако трябва да замените съществуващ пакетен файл, трябва отделно да премахнете този, който се заменя, след което да добавите новия. Не можете просто да копирате новия файл върху стария.

Конфигурирайте pacmanда използвате вашето локално хранилище, като редактирате /etc/pacman.confи добавете следното в края:

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

Трябва да pacmanопресните знанията му за хранилище, (включително вашето локално такова), бази данни; за да видите пакетите, които сте добавили към него:

# pacman -Sy

След това можете да инсталирате пакета, не по-различно, отколкото ако беше в официално хранилище:

# pacman -S <PKGNAME>

Имайте предвид, че ако пакетът е просто зависимост от друг пакет, който ще инсталирате, не е необходимо да го инсталирате директно. Когато инсталирате този друг пакет, pacmanавтоматично ще намери и инсталира пакетите на зависимости във вашето локално хранилище.

Компилиране по-бързо

По подразбиране YOUR BUILDERкомпилира с помощта на една нишка. При многопроцесорни системи можете да разрешите използването на множество нишки, където е възможно. Системата за изграждане ще компилира части от изходния код паралелно, когато може. Понякога части от кода изискват други части, с които взаимодейства, да бъдат вече компилирани, така че няма да виждате винаги използвани толкова нишки, колкото са разрешени. Редактиране /etc/makepkg.conf.

За да разрешите използването на толкова нишки, колкото имате виртуални ядра, добавете следното:

MAKEFLAGS="-j$(nproc)"

Забележка: Това ще изпълнява командата nprocвсеки път, така че винаги ще използва текущия брой ядра, в случай че надстроите вашия Vultr сървър

За да позволите използването на множество виртуални ядра, но не всички от тях, като например да намалите въздействието върху цялостната производителност на системата, добавете конкретен брой. Например, ако имате 24 ядра, можете да разрешите използването на 21:

MAKEFLAGS="-j21"

Посочването на повече нишки от броя на виртуалните ядра, които имате, ще намали производителността.

Това е доста рядко, но системите за изграждане на някои пакети имат проблеми с паралелната компилация, поради неправилно дефиниране на зависимости между части от кода. Обикновено PKGBUILDфайловете на тези пакети ще се справят с това вместо вас, като извикат make -j1, което отменя зададеното от вас по подразбиране. Ако има нужда от това и липсва, докладвайте го на поддържащия пакета Arch.

Грешка в подписа на PGP

А PKGBUILDмасив източник може да съдържа .ascили .sigфайлове. Те често се включват чрез разширение на bash скоби, така че могат лесно да бъдат пропуснати:

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

Ако някой от тези формати на файлове с подписи е включен в масива на източника, YOUR BUILDERавтоматично се опитва да провери подписа на архива на източника нагоре по веригата. PGP ключът на подписа трябва да бъде в ключодържателя на потребителя; в противен случай ще се прекрати с грешката:

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

Важно е да разберете, че GPG ключът може да бъде показан по няколко начина. Пръстовият му отпечатък е 40 шестнадесетични знака и е това, което винаги трябва да използвате. Дългият идентификатор на ключ е последните 16 цифри, а късият ключ е последните 8 цифри. Въпреки че по-краткият е удобен, той позволява дублиране, което анулира цялата аргументация зад проверката на подписите. По-лошото е, че е известно, че нападателите генерират фалшиви ключове, които съответстват на ключове с по-малка дължина за високопрофилни разработчици.

Вземете и потвърдете отпечатъка на PGP ключ

Ако още не сте опитвали да изградите пакета, изтеглете източниците, които ще включват файла с подписите: (Ако сте опитали да изградите, той вече ще бъде там)

$ makepkg --nobuild --noextract

За да получите пълния пръстов отпечатък:

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

В идеалния случай трябва да проверите този пръстов отпечатък от нагоре по веригата. За да бъде защитен, upstream трябва да даде ключовете на своите поддържащи някъде на своя уебсайт или в източника. Простото търсене на ключа на ключов сървър всъщност не прави нищо. Нападателят може лесно да изпрати фалшив ключ, тъй като ключовите сървъри не проверяват автентичността. Ключовете могат да бъдат подписани от други ключове, така че ако вече имате ключ, на който имате доверие, трябва да сте доста в безопасност, като се доверявате на всички ключове, които са подписали.

Това може да бъде доста работа, особено когато нагоре по веригата не публикува пръстовия си отпечатък или не го поставя на лесно място за намиране. В PKGBUILDще съдържа validpgpkeysмасив, които се прибавят от поддържащото Arch. Ако пакетът е официално хранилище, това означава, че доверен потребител го е поставил там и трябва да сте сравнително безопасни да се доверите на всичко, изброено в масива. Ако пакетът е в AUR, не забравяйте, че това просто означава, че друг потребител на Arch го е поставил там. Ако се притеснявате да му се доверите, винаги можете да погледнете в потребителя, за да видите какво са правили в миналото с Arch.

Добавете PGP ключ към вашия ключодържател

За да добавите пръстовия отпечатък към своя ключодържател:

$ gpg --recv-keys <FINGERPRINT>

Вече можете да стартирате YOUR BUILDERи той ще се довери на пръстовия отпечатък.

AUR пакети за развитие

AUR пакети с имена, завършващи -git, -svn, -bzrили -hgса версии за разработка, които използват най-новата система за контрол на версиите нагоре по веригата вместо най-новата версия на upstream. Например, а-gitпакетът ще използва най-новия комит на upstream в главния клон (или техния еквивалентен клон). Това е чудесно за стартиране на корекции на грешки и нови функции, които все още не са пуснати, и когато работите с upstream върху грешка, за която съобщавате, включително ако трябва да проверите за тях, че не е грешка, която е коригирана чрез комит, който все още не е в версия. Тези пакети трябва да се считат за потенциално нестабилни. Въпреки това, за съжаление, понякога няма алтернатива, защото някои поддържащи нагоре по веригата никога не маркират издания или преминават прекалено дълго между маркирането на издания и очакват всеки да използва най-новия си комит. В зависимост от пакета, вие може да сте първият човек, който се опитва да изпълни този комит. В зависимост от разработчиците нагоре по веригата, последният им комит може дори да не се компилира,

Важно е да разберете често срещана грешка. Не маркирайте пакет за разработка на AUR като остарял, просто защото показва номер на стара версия! PKGBUILDФайловете с пакети за развитие съдържат допълнителна функция pkgver(), която се използва за автоматично анализиране на актуализиран PKGVERот изходния код нагоре по веригата. Често срещан формат за -gitпакет е <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Пакет може да бъде посочен в AUR като 5.0.0.r102.8d7b42ac21-1, защото това е, което PKGBUILDсъдържа. Но когато създадете пакет, YOUR BUILDERтой автоматично ще се актуализира, за PKGVERда отразява новоизтегления изходен код. Всъщност, ако са пуснати много нови версии, но нищо не се е променило в процеса на изграждане, такъв PKGBUILDсписък на стара версия може да доведе до изграждане на нещо много по-ново, като напр.9.1.2.r53.2c9a41b723-1. За тези пакети версията, посочена на уебсайта, е просто най-новата версия към момента, в който поддържащият AUR последно трябваше да актуализира PKGBUILD.

Поддръжниците на AUR НЕ трябва просто да актуализират, за PKGVERда отразяват новите версии. Те трябва да го правят само когато по-новите ангажименти нагоре по веригата всъщност изискват нещо друго в PKGBUILDпромяната.

Маркирайте неактуален пакет AUR за развитие само ако знаете, че нещо не е наред. Това означава, че всъщност сте опитали да го използвате и той не успява да компилира или анализира правилно форматиран нов PKGVER. Понякога се случват неща, които принуждават поддържащия AUR да актуализира PKGBUILD, като промяна на зависимостите нагоре по веригата, промяна на configureопциите, новите версии на GCC улавят грешки в изходния код, които предишните не са правили, местоположението на хранилището нагоре по веригата се променя или разработчиците нагоре по веригата ще променят там, където типичната им версия е в изходния код, който нарушаваPKGVERфункция за синтактичен анализ. Разберете, че дори ако не успее да се компилира или работи, това може да означава, че поддържащият на AUR трябва да направи промени в процеса на изграждане, или може да е проблем нагоре по веригата с техния изходен код, за който поддържащият AUR не носи отговорност.

Остарели пакети

Не забравяйте да прочетете секцията „Пакети за развитие на AUR“ по-горе, преди да съобщите, че пакет е остарял!

Ако upstream е пуснал по-нова версия за пакет, който не е за разработка, отколкото в PKGBUILD, можете да щракнете върху „Flag package out-of-date“ и да въведете съобщение до поддържащия. Използвайте https://packages.archlinux.org за официални пакети за хранилище и https://aur.archlinux.org за AUR пакети. Полезно съобщение би било новият номер на версията и може би връзка към съобщението за изданието или изходния код. Функцията за маркиране автоматично изпраща съобщението ви по имейл до поддържащия.

При пакет AUR, ако няма отговор след 2 седмици, можете да щракнете върху „Изпращане на заявка“ с тип „Орфан“, ако искате да помолите доверен потребител да премахне текущия поддържащ и да направи пакета осиротен, ако поддържащият не отговаря на молбата за сирак. Обикновено хората подават заявки за сираци само ако са в състояние и желаят да поемат пакета и за предпочитане само ако вече имат работещ ток PKGBUILD.

Междувременно често можете сами да актуализирате остарял пакет. Често трябва да промените само a, PKGBUILDкато актуализирате PKGVERдо новия номер на версията и сумите за интегритет да бъдат актуализирани. Програма updpkgsumsсъществува в пакет pacman-contrib, който автоматично изчислява сумите и ги актуализира PKGBUILDза вас. Струва си да проверите бележките към версията нагоре по веригата, за да видите дали те споменават, че нещо трябва да се промени по време на инсталационния процес на новата версия. Понякога промените нагоре по веригата изискват повече промени или основни ремонти за PKGBUILD/ETC. Често sourceмасивът се вгражда PKGVERв него, така че често дори не се нуждае от актуализиране.