makepkg (Русский)

From ArchWiki
Jump to navigation Jump to search

Tango-preferences-desktop-locale.pngЭта страница нуждается в сопроводителеTango-preferences-desktop-locale.png

Статья не гарантирует актуальность информации. Помогите русскоязычному сообществу поддержкой подобных страниц. См. Команда переводчиков ArchWiki
Состояние перевода: На этой странице представлен перевод статьи Makepkg. Дата последней синхронизации: 8 октября 2019. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

makepkg — скрипт автоматизации сборки пакетов. Системные требования скрипта включают в себя наличие файла PKGBUILD и UNIX-платформы с поддержкой сборки.

makepkg поставляется с пакетом pacman.

Contents

Настройка

Обратитесь к makepkg.conf(5), чтобы узнать больше о возможных опциях настройки makepkg.

Общесистемные настройки доступны в файле /etc/makepkg.conf, пользовательские — в $XDG_CONFIG_HOME/pacman/makepkg.conf или ~/.makepkg.conf. Перед сборкой пакетов рекомендуется проверять настройки.

Информация о создателе пакета

Каждый пакет обладает метаданными, в которых, помимо прочего, содержится информация о создателе пакета ("packager"). Если этот параметр не задан, то при создании пакета ему присваивается значение по умолчанию — Unknown Packager. Однако если компиляцией пакетов занимаются несколько пользователей на одном компьютере или планируется распространять пакет другим пользователям, то имеет смысл указать настоящие контактные данные, задав переменной PACKAGER необходимое значение в файле makepkg.conf.

Проверить данный параметр в установленном пакете можно следующим образом:

$ pacman -Qi пакет
...
Packager       : John Doe <john@doe.com>
...

Также задайте значение переменной GPGKEY в файле makepkg.conf для автоматического создания подписанных пакетов.

Выходные файлы пакета

По умолчанию makepkg создаёт архив пакета в формате tar в рабочем каталоге, а исходный код загружает в каталог src/. Расположение целевых каталогов можно переназначить, например, так, чтобы все собранные пакеты хранились в ~/build/packages/, а все исходные данные — в ~/build/sources/.

Необходимо задать следующие значения в makepkg.conf:

  • PKGDEST — каталог хранения итоговых пакетов (с расширением .pkg.tar.xz)
  • SRCDEST — каталог хранения исходных данных (символические указатели будут размещены в src/, если данные указывают на какое-либо другое расположение)
  • SRCPKGDEST — каталог хранения итоговых исходных пакетов (с расширением .src.tar.gz и собранных с помощью команды makepkg -S)
Совет: Каталог PKGDEST можно очистить, например, командой paccache -c ~/build/packages/, как описано в разделе pacman (Русский)#Очистка кэша пакетов.

Проверка подписей

Примечание: Реализованная в makepkg проверка подписей не использует связки ключей ("keyring") pacman, а полагается исключительно на пользовательские связки. [1]

Если файл подписи с расширением .sig или .asc является частью массива source в файле PKGBUILD, то makepkg автоматически попытается проверить его. В случае если пользовательская связка ключей не содержит необходимый для подтверждения сигнатур публичный ключ, то makepkg прервёт установку, выведя сообщение о невозможности проверки PGP-ключа.

Если необходимый публичный ключ отсутствует, то PKGBUILD, скорее всего, содержит пункт validpgpkeys с идентификаторами ключей. Ключи можно импортировать вручную или же найти их на сервере ключей и импортировать оттуда.

Использование

Для корректной работы makepkg необходимо предварительно установить группу пакетов base-devel. Пакеты из этой группы не обязательно указывать в качестве зависимосимостей для сборки (makedepends) в файлах PKGBUILD.

Примечание:
  • Убедитесь, что утилита sudo настроена должным образом для команд, передаваемых pacman.
  • Запуск makepkg от root-пользователя запрещён.[2] Поскольку PKGBUILD может содержать произвольные команды, сборка пакетов под root-аккаунтом признана небезопасной.[3] Если у пользователя нет доступа к обычному пользовательскому аккаунту, то следует запускать makepkg от имени пользователя "nobody".

Чтобы собрать пакет, первым делом необходимо создать файл PKGBUILD, скрипт сборки, как описано в статье Создание пакетов. Существующие скрипты доступны в дереве каталогов Системы сборки Arch (ABS), а также в AUR. После получения PKGBUILD переместитесь в его каталог и выполните следующую команду, чтобы собрать пакет:

$ makepkg

Если необходимые зависимости не установлены, makepkg предупредит вас об этом перед тем как отменить сборку. Чтобы собрать пакет и установить все необходимые зависимости, добавьте флаг -s/--syncdeps:

$ makepkg --syncdeps

С добавленным флагом -r/--rmdeps makepkg также удалит установленные зависимости для сборки, если они больше будут не нужны. Если вы постоянно занимаетесь сборкой пакетов и не хотите загрязнять систему пакетами-сиротами, то будет также полезно ознакомиться с удалением неиспользуемых пакетов.

Примечание:
  • Пакеты, устанавливаемые в качестве зависимостей, должны находиться в настроенных репозиториях; детали настроек смотрите в разделе Pacman (Русский)#Репозитории. Помимо этого, можно установить зависимости вручную перед началом сборки (pacman -S --asdeps зависимость1 зависимость2).
  • При установке зависимостей используются только глобальные значения переменных, то есть, к примеру, попытки переопределения значений внутри функции упаковки разделённого пакета (split package) не сработают. [4]

Когда все зависимости установлены и сборка пакета завершилась успешно, в рабочем каталоге появится файл пакета (имя-пакета-версия-пакета.pkg.tar.xz). Чтобы установить его в систему, используйте флаг -i/--install (что идентично команде pacman -U имя-пакета-версия-пакета.pkg.tar.xz):

$ makepkg --install

Для удаления оставшихся файлов и каталогов, таких как распакованные в $srcdir файлы, используйте флаг -c/--clean. Это полезно в случае многократных сборок одного и того же пакета или обновления его версии, если используется один и тот же рабочий каталог. Это предотвращает добавление устаревших файлов в новые сборки:

$ makepkg --clean

См. makepkg(8) для получения дополнительной информации.

Советы и рекомендации

Создание оптимизированных двоичных пакетов

Повышение производительности программного обеспечения может быть достигнуто с помощью оптимизации работы компилятора на этапе сборки пакета. С другой стороны, нужно иметь в виду, что двоичные файлы, скомпилированные под специфическую архитектуру процессора, не будут правильно работать на других машинах. Если говорить об архитектуре x86_64, то редко когда достигнутый эффект повышения производительности стоит затраченного на пересборку официальных пакетов времени.

В то же время нужно помнить, что снизить производительность путём установки "нестандартных" флагов компилятора очень легко. Чаще всего тонкая настройка компилятора приносит пользу лишь в определённой ситуации и не должна применяться ко всем пакетам без разбора. Если вы не можете доказать повышение производительности путем тестов, то скорее всего, её просто нет! Статьи из Gentoo-wiki Оптимизации GCC и Safe CFLAGS содержат больше информации об оптимизации компилятора.

Опции, переданные C/C++ компилятору (например, gcc или clang) зависят от переменных окружения CFLAGS, CXXFLAGS и CPPFLAGS. В Системе сборки Arch makepkg извлекает переменные окружения из файла конфигурации makepkg.conf и использует их в качестве опций. Значения по умолчанию выбраны таким образом, чтобы создаваемые двоичные пакеты могли устанавливаться на широким диапазоне машин.

Примечание:
  • Следует помнить, что не все системы сборки используют переменные, указанные в makepkg.conf. Например, cmake пренебрегает переменной опций препроцессора, CPPFLAGS. Как следствие, многие файлы PKGBUILD содержат обходные решения, необходимые для системы сборки, используемой для конкретного программного обеспечения.
  • Настройки, указанные в файле Makefile или специфический аргумент в команде компиляции имеет приоритет над значениями в makepkg.conf, что может привести к их переопределению.

Компилятор GCC может автоматически обнаруживать и включать безопасные оптимизации, доступные для конкретной архитектуры. Чтобы использовать эту особенность, сначала удалите любые -march и -mtune флаги, а затем добавьте опцию -march=native. Например:

/etc/makepkg.conf
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong -fno-plt"
CXXFLAGS="${CFLAGS}"

Чтобы узнать, какие флаги эта команда разблокирует на вашей машине, выполните:

$ gcc -march=native -v -Q --help=target
Примечание: Если вы укажете значение, отличное от -march=native, то -Q --help=target не сработает, как должно. [5] Вам придётся пройти через фазу компиляции, чтобы узнать, какие опции на самом деле были включены.

Сокращение времени компиляции

Параллельная компиляция

Для сборки пакетов с помощью make используется переменная окружения MAKEFLAGS, которая определяет дополнительные опции для утилиты make. Установить значение этой переменной можно также в файле makepkg.conf.

Пользователи с многоядерными/многопроцессорными системами могут указать количество задач, запускаемых одновременно. Это делается с помощью утилиты для определения количества доступных ядер nproc, например MAKEFLAGS="-j$(nproc)". Некоторые файлы PKGBUILD переопределяют это значение на -j1, чтобы избежать состояний гонки или просто потому что многопоточная работа не поддерживается изначально. Если сборка пакета завершилась неудачно из-за описанных выше изменений в MAKEFLAGS, то нужно создать отчёт об ошибке или, в случае пакета из AUR, сообщить сопроводителю пакета.

Чтобы узнать о других доступных опциях, обратитесь к make(1).

Сборка из файлов в памяти

Если компиляция требует много операций ввода-вывода и обработки маленьких файлов, перемещение рабочего каталога во временную файловую систему tmpfs может сократить время компиляции.

Переменная BUILDDIR может быть временно экспортирована в makepkg, чтобы установить рабочий каталог в существующий раздел с tmpfs. Например:

$ BUILDDIR=/tmp/makepkg makepkg

Чтобы сделать эту настройку постоянной, нужно раскомментировать опцию BUILDDIR исходного файла настроек /etc/makepkg.conf. Если, к примеру, установить это значение BUILDDIR=/tmp/makepkg, то будет использоваться обычная временная файловая система Arch /tmp.

Примечание:
  • Старайтесь не компилировать большие пакеты в tmpfs, чтобы не произошло исчерпания памяти.
  • Каталог tmpfs должен быть смонтирован без опции noexec, потому что иначе собранный двоичный пакет будет невозможно исполнить.
  • Также помните, что собранные в tmpfs пакеты будут удалены при перезагрузке. Задайте опцию PKGDEST[broken link: invalid section], чтобы собранный пакет автоматически перемещался в "постоянный" каталог.

Использование кэша компиляции

Применение ccache может уменьшить время сборки за счет многократного использования кэша компиляции.

Вычисление новых контрольных сумм

Установите пакет pacman-contrib и выполните следующую команду в каталоге с файлом PKGBUILD, чтобы сгенерировать новые контрольные суммы:

$ updpkgsums

Контрольные суммы также можно получить посредством команды sha256sum, после чего полученные значения следует добавить к массиву sha256sums в файле PKGBUILD вручную.

Применение других алгоритмов сжатия

Создание и установку пакета можно ускорить, заплатив за это увеличением размера. Для этого нужно изменить переменную окружения PKGEXT. Например, для создания пакета в виде несжатого архива необходимо выполнить команду:

$ PKGEXT='.pkg.tar' makepkg

Другой пример, с использованием алгоритма сжатия lzop (необходим пакет lzop):

$ PKGEXT='.pkg.tar.lzo' makepkg

Чтобы сделать одну из этих настроек постоянной, нужно установить соответствующее значение PKGEXT в /etc/makepkg.conf.

Использование нескольких ядер при сжатии

xz поддерживает симметричную многопроцессорность (SMP) посредством флага --threads для ускорения сжатия. Например, чтобы разрешить makepkg использовать все имеющиеся в наличии ядра CPU, отредактируйте массив COMPRESSXZ в /etc/makepkg.conf:

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

pigz — параллельная реализация gzip, по умолчанию использует все доступные ядра CPU. Если необходимо задействовать меньшее количество ядер, то используется флаг -p/--processes:

COMPRESSGZ=(pigz -c -f -n)

pbzip2 — параллельная реализация bzip2, также использует максимально возможное количество ядер по умолчанию. Флаг -p# используется для выбора меньшего количества ядер (примечание: между -p и числом ядер не должно быть пробелов):

COMPRESSBZ2=(pbzip2 -c -f)

Вывод списка пакетов по имени создателя

Если необходимо вывести список всех установленных пакетов, создателем которых является создатель-пакета, выполните:

$ expac "%n %p" | grep "создатель-пакета" | column -t

Для вывода списка пакетов, создатель которых указан в переменной PACKAGER файла /etc/makepkg.conf (покажет только пакеты из репозиториев, определенных в /etc/pacman.conf):

$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)

Сборка 32-битных пакетов в 64-битной системе

Важно: Если вы попытаетесь собрать пакет linux указанным ниже способом, результатом будет сообщение об ошибке.

Предварительно разблокируйте репозиторий multilib и установите группу пакетов multilib-devel.

Затем создайте 32-битный файл настроек

~/.makepkg.i686.conf
CARCH="i686"
CHOST="i686-unknown-linux-gnu"
CFLAGS="-m32 -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-m32 -Wl,-O1,--sort-common,--as-needed,-z,relro"

и выполните makepkg следующим образом:

$ linux32 makepkg --config ~/.makepkg.i686.conf

Решение проблем

CFLAGS/CXXFLAGS/LDFLAGS в makepkg.conf не работают для пакетов на основе CMake

Чтобы CMake мог применить значения переменных, определенных в makepkg.conf, просто не используйте флаг -DCMAKE_BUILD_TYPE в процессе настройки проекта cmake. [6]

В результате CMake применит тип сборки None, что позволит использовать переменные окружения CFLAGS, CPPFLAGS и т.д.

CFLAGS/CXXFLAGS/LDFLAGS в makepkg.conf не работают для пакетов на основе QMake

Qmake автоматически устанавливает переменные CFLAGS, CXXFLAGS and LDFLAGS, руководствуясь своими внутренними настройками. Если необходимо, чтобы Qmake использовал значения из makepkg.conf, нужно отредактировать PKGBUILD и передать Qmake переменные QMAKE_CFLAGS, QMAKE_CXXFLAGS and QMAKE_LFLAGS. Например:

PKGBUILD
...

build() {
  cd "$srcdir/$_pkgname-$pkgver-src"
  qmake-qt5 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \
    PREFIX=/usr \
    QMAKE_CFLAGS="${CFLAGS}" \
    QMAKE_CXXFLAGS="${CXXFLAGS}" \
    QMAKE_LFLAGS="${LDFLAGS}"

  make
}

...

В качестве альтернативы можно создать файл системных настроек qmake.conf и установить переменную окружения QMAKESPEC.

Назначение установочного каталога для пакетов на основе QMAKE

Генерируемый Qmake файл makefile использует переменную окружения INSTALL_ROOT чтобы указать, куда программа должна быть установлена. Например, в функции package:

PKGBUILD
...

package() {
	cd "$srcdir/${pkgname%-git}"
	make INSTALL_ROOT="$pkgdir" install
}

...

Обратите внимание, что Qmake тоже должен быть соответствующим образом сконфигурирован. К примеру, добавьте следующие строки в ваш .pro файл.

YourProject.pro
...

target.path = /usr/local/bin
INSTALLS += target

...

WARNING: Package contains reference to $srcdir

Подобное предупреждение означает, что строковый литерал, указанный в переменных $srcdir или $pkgdir, каким-то образом оказался в одном или нескольких файлах вашего пакета [7].

Чтобы определить, в каких именно файлах, выполните следующую команду в рабочем каталоге сборки:

$ grep -R "$(pwd)/src" pkg/

Одной из причин появления этого предупреждения может быть использованный в коде C/C++ макрос __FILE__, содержащий полный путь к каталогу $srcdir.

Makepkg не может загрузить зависимости через прокси

Когда makepkg проверяет зависимости, он вызывает pacman для установки пакетов, который требует предоставления прав администратора посредством sudo. Однако команда sudo не передает никакие переменные окружения в привилегированное окружение, в том числе и относящиеся к настройкам прокси переменные ftp_proxy, http_proxy, https_proxy и no_proxy.

Чтобы makepkg мог работать через прокси, воспользуйтесь одним из советов ниже.

Установите URL прокси-сервера в XferCommand

XferCommand можно настроить для использования указанного в /etc/pacman.conf URL прокси. Добавьте или раскомментируйте следующую строку:

/etc/pacman.conf
...
XferCommand = /usr/bin/curl -x http://username:password@proxy.proxyhost.com:80 -L -C - -f -o %o %u
...

Разблокируйте прокси в файле /etc/sudoers

Опция env_keep в файле /etc/sudoers позволяет использовать упомянутые выше прокси-переменные в привилегированном окружении. За подробной информацией обратитесь к Sudo (Русский)#Переменные окружения.

Makepkg не работает, но make завершается успешно

Если пакет компилируется вручную с помощью make, но не посредством makepkg, причиной могут быть переменные компиляции в файле /etc/makepkg.conf. Попробуйте добавить следующие флаги к массиву options файла PKGBUILD:

!buildflags, для отключения значений по умолчанию CPPFLAGS, CFLAGS, CXXFLAGS, и LDFLAGS.

!makeflags, для отключения MAKEFLAGS, если вы меняли /etc/makepkg.conf чтобы разрешить параллельную сборку.

!debug, для отключения DEBUG_CFLAGS и DEBUG_CXXFLAGS, если вы собрали пакет для дебага.

Если что-то из перечисленного выше решило проблему, выясните, какой именно флаг создавал проблему и сообщите о баге разработчикам.

Смотрите также