Створення пакетів на Arch Linux (включаючи AUR)

В Arch Linux офіційні репозиторії: core, extra та community. Ці пакунки вже скомпільовані, і вони встановлені через pacman. Здебільшого звичайні користувачі можуть ігнорувати, що ці 3 офіційні репозиторії є окремими. Ядро містить найважливіші пакунки, такі як ядро, процес завантаження, мережа, керування пакетами, openssh тощо. Він також має суворіші вимоги до більш ретельного тестування перед випуском нових версій. Extra містить інші популярні пакети, які не такі критичні, як-от X-сервер, менеджери вікон або веб-браузери. Спільнота містить менш популярні пакети. Тільки довірені користувачі (близько 60 активних користувачів, за яких проголосували інші довірені користувачі) мають доступ до внесення змін до офіційних сховищ.

У 2019 році в офіційних сховищах за адресою https://www.archlinux.org/packages знаходиться близько 11 000 пакетів . Але в Linux є багато інших програм. Отже, AUR (сховище користувачів Arch Linux) існує, тому будь-який користувач Arch може додати нову програму і стати її супроводжувачем, або прийняти «осиротілий» пакет без поточного супроводжувача. В AUR на сайті https://aur.archlinux.org/ є близько 55 000 пакетів .

Є 3 критичні відмінності від AUR:

1. Знову ж таки, ці пакети може виготовити будь-який користувач, навіть новий.
2. AUR містить лише PKGBUILDсценарій оболонки для автоматичного створення пакунка, а не скомпільовані двійкові файли. (Іноді він також містить невеликі текстові виправлення або сценарії встановлення/оновлення/видалення оболонки). Це зробило величезну роботу, дозволивши будь-якому користувачеві зробити свій внесок, одночасно зменшивши ймовірність того, що хтось зможе поширювати шкідливий код. Спільнота Arch все ще досить корисна щодо проблем з пакетами AUR, але зазначається, що ви використовуєте їх на свій страх і ризик. Оскільки все, що він надає, — це PKGBUILD, зрештою, ви зобов’язані переглянути файл, який PKGBUILDви збираєтеся використовувати. (Зрозуміло, багато користувачів цього не роблять і просто покладаються на інших, щоб спостерігати.)
3. Оскільки pacmanвін не взаємодіє безпосередньо з AUR, ви несете відповідальність за оновлення пакетів AUR. Коли ви періодично оновлюєте всю свою систему за допомогою pacman, вона не завантажуватиме оновлення PKGBUILDфайлів AUR автоматично , не компілює їх та не встановлює для вас.

Хоча ця стаття зосереджується на створенні пакетів з 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: версія пакета (майже завжди відповідає номеру версії upstream)
• PKGREL: «Версія» Arch PKGBUILDдля певного PKGVER(зазвичай 1, але збільшується, якщо потрібно внести зміни PKGBUILDміж попередніми випусками)
• ARCH: Архітектура, на якій може бути побудований пакет (дещо застаріла, оскільки офіційні репозиторії Arch Linux підтримують лише "x86_64" (64-розрядні ЦП), але пакети AUR все ще можуть підтримувати "i686" (32-розрядні ЦП) або "будь-який" позначати архітектуру не має значення)
• PKGBUILD/ETC: Будь-які файли фактично в сховищі AUR; то PKGBUILD, і будь-які інші дрібні текстові патчі, або встановити / оновити / видалення скриптів. Не включає файли вгорі по потоку в sourceмасив.

Незважаючи на те, що AUR виявився надзвичайно надійним, варто подивитися на a, PKGBUILD/ETCщоб переконатися, що він отримує джерело з місця, якому ви готові довіряти; (наприклад, офіційне розташування, яке може бути з github, але не просто репозиторій github якоїсь випадкової людини, який не має відношення до пакета upstream); і що 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>

Note if the package is merely a dependency of another package you are going to install, you don't need to install it directly. When you install this other package, pacman will automatically find and install the dependency packages in your local repository.

Compile Faster

By default, YOUR BUILDER compiles using a single thread. On multi CPU systems, you can allow using multiple threads where possible. The build system will compile parts of the source code in parallel when it can. Sometimes parts of code require other parts it interacts with to already be compiled, so you won't always see as many threads being used as are allowed. Edit /etc/makepkg.conf.

To allow using as many threads as you have virtual cores, add the following:

MAKEFLAGS="-j$(nproc)"

Note: This will run the command nproc every time, so it will always use the current number of cores, in case you upgrade your Vultr server

To allow using multiple virtual cores, but not all of them, such as to reduce impact to overall system performance, add a specific number. For example, if you have 24 cores, you could allow 21 to be used:

MAKEFLAGS="-j21"

Specifying more threads than the number of virtual cores you have will decrease performance.

It's fairly rare, but some packages' build systems have problems with parallel compilation, from not properly defining dependencies between parts of code. Typically, those packages' PKGBUILD files will handle this for you by invoking make -j1, which overrides the default you set. If it needs this and it's missing, report it to the Arch package maintainer.

Помилка підпису 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 має надати ключі своїх супроводжувачів десь на своєму веб-сайті або в джерелі. Простий пошук ключа на сервері ключів насправді нічого не робить. Зловмисник може легко подати підроблений ключ, оскільки сервери ключів не перевіряють справжність. Ключі можуть бути підписані іншими ключами, тому, якщо у вас уже є ключ, якому ви довіряєте, ви повинні бути досить безпечними, довіряючи будь-яким ключам, які вони підписали.

Це може бути чимало роботи, особливо коли upstream не публікує відбиток пальця або не розміщує його в тому місці, де його легко знайти. PKGBUILDМіститиме validpgpkeysмасив, які були додані до супроводжуючого Arch. Якщо пакунок є офіційним сховищем, це означає, що довірений користувач розмістив його туди, і ви повинні бути досить безпечними, щоб просто довіряти всьому, що перераховано в масиві. Якщо пакет знаходиться в AUR, пам’ятайте, що це означає, що інший користувач Arch помістив його туди. Якщо ви стурбовані довірою до нього, ви завжди можете подивитися на користувача, щоб побачити, що він робив у минулому з Arch.

Додайте ключ PGP до свого брелока

Щоб додати відбиток пальця до брелока:

$ gpg --recv-keys <FINGERPRINT>

Тепер ви можете запустити YOUR BUILDER, і він буде довіряти відбитку пальця.

Пакети розвитку AUR

AUR пакети з іменами , що закінчуються -git, -svn, -bzrабо -hgє версії розвитку, які використовують вгору по течії в останню систему контролю версій зробити замість вище це останній реліз. Наприклад, а-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, ви можете натиснути «Позначити пакет застарілий» і ввести повідомлення для супроводжувача. Використовуйте https://packages.archlinux.org для офіційних пакетів репозитарію та https://aur.archlinux.org для пакетів AUR. Корисним повідомленням буде номер нової версії і, можливо, посилання на оголошення про випуск або вихідний код. Функція позначення автоматично надсилає ваше повідомлення електронною поштою супроводжувачу.

Якщо у пакеті AUR немає відповіді через 2 тижні, ви можете натиснути «Надіслати запит» із типом «Orphan», якщо ви хочете попросити довіреного користувача видалити поточного супроводжувача та зробити пакет бездіяльним, якщо супроводжувач не відповідає на запит сироти. Як правило, люди подають запити-сироти лише в тому випадку, якщо вони здатні та бажають прийняти пакет, і бажано лише якщо вони вже мають робочий поточний PKGBUILD.

Тим часом ви часто можете самостійно оновити застарілий пакет. Часто вам потрібно лише змінити a PKGBUILD, оновивши номер PKGVERдо нової версії, і оновити суми цілісності. Програма updpkgsumsіснує в пакеті pacman-contrib, яка автоматично обчислює суми та оновлює їх у файлі PKGBUILDдля вас. Варто перевірити примітки до випуску upstream, щоб побачити, чи не згадується в них, що потрібно щось змінити під час процесу встановлення нової версії. Іноді зміни, що виникли нагорі, вимагають додаткових змін або капітального ремонту для PKGBUILD/ETC. Часто sourceмасив вбудовується PKGVERв нього, тому часто навіть не потребує оновлення.