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

• PKGBUILD
• Получение PKGBUILD / ETC
• Обновление PKGBUILD / ETC
• составление
• Локальный репозиторий
• Компилировать быстрее
• Ошибка подписи PGP
• AUR Развивающие Пакеты
• Устаревшие пакеты

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

В 2019 году в официальных репозиториях на https://www.archlinux.org/packages было размещено около 11 000 пакетов . Но есть много других программ, доступных в Linux. Таким образом, AUR (Arch Linux User Repository) существует, поэтому любой пользователь Arch может добавить новую программу и стать ее сопровождающим, или принять «осиротевший» пакет без текущего сопровождающего. В AUR есть около 55 000 пакетов по адресу https://aur.archlinux.org/ .

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

Несмотря на то, что AUR оказался чрезвычайно надежным, стоит взглянуть на него, PKGBUILD/ETCчтобы убедиться, что он получает источник из места, которому вы готовы доверять; (например, официальный апстрим-сайт, который может быть из github - но не просто репозиторий какого-то случайного человека, который не связан с пакетом апстрима); и что PKGBUILD/ETCон не содержит подозрительного кода.

получение PKGBUILD/ETC

От AUR

Если в официальных репозиториях нет пакета, который вы хотите установить, найдите его по адресу https://aur.archlinux.org/ . Надеюсь, вы обнаружите, что то, что вы ищете, существует, обновлено и поддерживается.

Лучший способ получить PKGBUILD/ETCAUR - это клонировать его через git.

Установите git, если это еще не сделано:

# pacman -S git

Используйте «URL Git Clone», показанный на веб-сайте AUR для этого пакета:

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

Войдите в каталог и посмотрите на его содержимое. (Все перечисленное здесь, кроме как . .. .gitесть PKGBUILD/ETC):

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

Если вы посмотрите PKGBUILD, вы, вероятно, увидите, что он использует официальный исходный код и выполняет типичные шаги для сборки пакета, поэтому он кажется заслуживающим доверия. .SRCINFOСодержит только информацию , отображаемую на веб - сайте о пакете, поэтому не вызывает тревогу. Если здесь есть какие-либо другие файлы, они не (напрямую) предоставляются вышестоящим, поэтому следует проверить файлы и то, как они используются в 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 brace, поэтому их легко пропустить:

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
...

В идеале вы должны проверить этот отпечаток пальца вверх по течению. Чтобы быть в безопасности, апстрим должен давать ключи своего сопровождающего где-нибудь на своем веб-сайте или в источнике. Простой поиск ключа на сервере ключей ничего не делает. Злоумышленник может легко отправить поддельный ключ, поскольку серверы ключей не проверяют подлинность. Ключи могут быть подписаны другими ключами, поэтому, если у вас уже есть ключ, которому вы доверяете, вы должны быть в безопасности, доверяя всем ключам, которые они подписали.

Это может быть довольно трудоемким делом, особенно, когда апстрим не публикует свой отпечаток пальца или не размещает его где-нибудь, где его легко найти. PKGBUILDБудет содержать validpgpkeysмассив, которые были добавлены к сопровождающему Arch. Если пакет является официальным репозиторием, это означает, что Trusted User поместил его туда, и вы должны быть совершенно уверены, что можете доверять всему, что перечислено в массиве. Если пакет находится в AUR, помните, что это просто означает, что другой пользователь Arch разместил его там. Если вы беспокоитесь о доверии, вы всегда можете заглянуть в пользователя, чтобы увидеть, что он сделал в прошлом с Arch.

Добавить ключ PGP в ваш брелок

Чтобы добавить отпечаток пальца в ваш брелок:

$ gpg --recv-keys <FINGERPRINT>

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

AUR Развивающие Пакеты

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

Важно понимать распространенную ошибку. Не отмечайте пакет разработки 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» выше, прежде чем сообщать о том, что пакет устарел!

Если апстрим выпустил более новую версию для не относящегося к разработке пакета, чем в PKGBUILD, вы можете нажать «Пометить пакет как устаревший» и напечатать сообщение для сопровождающего. Используйте https://packages.archlinux.org для официальных пакетов репозитория и https://aur.archlinux.org для пакетов AUR. Полезным сообщением будет новый номер версии и, возможно, ссылка на объявление о выпуске или исходный код. Функция пометки автоматически отправляет ваше сообщение по электронной почте сопровождающему.

В пакете AUR, если через 2 недели не было ответа, вы можете нажать «Отправить запрос» с типом «Сирота», если вы хотите попросить Доверенного пользователя удалить текущего сопровождающего и сделать пакет потерянным, если сопровождающий не отвечает на сиротский запрос. Как правило, люди подают бесхозные запросы только в том случае, если они могут и хотят принять пакет, и желательно, только если у них уже есть рабочий ток PKGBUILD.

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