makepkg (Русский) - ArchWiki

# makepkg (Русский)

From ArchWiki
Jump to navigation Jump to search

Ссылки по теме

- Создание пакетов
- PKGBUILD (Русский)
- .SRCINFO
- Пользовательский репозиторий Arch
- pacman (Русский)
- Официальные репозитории
- Система сборки Arch

Эта страница нуждается в сопроводителе

Статья не гарантирует актуальность информации. Помогите русскоязычному сообществу поддержкой подобных страниц. См. Команда переводчиков ArchWiki

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

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

## Настройка

Обратитесь к 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][3]. Поскольку `PKGBUILD` может содержать произвольные команды, сборка пакетов под root-аккаунтом признана небезопасной [4]. Если у пользователя нет доступа к обычному пользовательскому аккаунту, то следует запускать makepkg от лица "nobody user".

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

    $ makepkg

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

    $ makepkg --syncdeps

Добавление опции `-r/--rmdeps` скажет makepkg, что необходимо удалить установленные зависимости позже, если они больше будут не нужны. Если вы постоянно занимаетесь сборкой пакетов и не хотите загрязнять систему пакетами-сиротами, то будет также полезно ознакомиться с Pacman (Русский)/Tips and tricks (Русский)#Удаление неиспользуемых пакетов.

Примечание:

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

Когда все зависимости установлены и сборка пакета завершилась успешно, в рабочем каталоге появится файл пакета `имя-и-версия-пакета.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, чтобы собранный пакет автоматически перемещался в "постоянный" каталог.

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

Применение 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/

### 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`, если вы собрали пакет для дебага.

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

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

- Справочная страница makepkg(8)
- Справочная страница makepkg.conf(5)
- Краткое описание работы makepkg
- Исходный код makepkg

Categories:

- Package development (Русский)
- About Arch (Русский)
- Commands (Русский)
- Русский