Автор: Хуан Ромеро Пардинес (Juan Romero Pardines) aka Juan PR
Перевод: Алексей Федорчук
Оригинал: The XBPS source packages collection
Этот репозиторий содержит коллекцию исходников пакетов XBPS для сборки бинарных пакетов дистрибутива Void Linux.
Содержащийся в нём сценарий xbps-src script
предназначен для получения исходных текстов программ и их компиляции, с последующей установкой файлов в ложный целевой каталог для генерации бинарных пакетов XBPS, которые могут быть установлены или запрошены с помощью утилит xbps-install(1)
и xbps-query(1)
, соответственно.
Системные требования
- GNU bash
- xbps >= 0.46
Для работы сценария xbps-src
необходимы операции chroot
и bind-монтирования существующего каталога в мастер-каталог, который используется как главный корневой каталог. В xbps-src
поддерживается несколько утилит для выполнения этих задач:
- xbps-uunshare(1) — утилита XBPS, использующая user_namespaces(7) (часть xbps, по умолчанию);
- xbps-uchroot(1) — утилита XBPS, использующая user_namespaces(7), которая должна иметь setgid (часть xbps);
- proot(1) — утилита, выполняющая chroot и bind-монтирование в пользовательском пространстве, см. http://proot.me.
Примечание: не обязательно иметь права root’а для использования
xbps-src
, лучше использовать стиль chroot, как показано ниже.
xbps-uunshare(1)
Эта утилита требует таких опций ядра Linux:
CONFIG_NAMESPACES CONFIG_IPC_NS CONFIG_UTS_NS CONFIG_USER_NS
Это — метод работы по умолчанию, и если система не поддерживает какую-либо из указанных опций ядра, он не будет выполнен с сообщением EINVAL
(Invalid argument).
xbps-uchroot(1)
Эта утилита требует таких опций ядра Linux:
CONFIG_NAMESPACES CONFIG_IPC_NS CONFIG_PID_NS CONFIG_UTS_NS
Пользователь должен быть добавлен в специальную группу для использования xbps-uchroot
и получить setgid
:
# chown root:xbps-uchroot # chmod 4750 xbps-uchroot # usermod -a -G
Примечание: по умолчанию вручную это не делается, пользователь уже должен быть членом группы xbuilder
. Для этого нужно:
$ cd void-packages $ echo XBPS_CHROOT_CMD=uchroot >> etc/conf
Если это почему-то вызывает ошибку типа Operation not permitted
, следует проверить, является ли пользователем членом нужной группы, и имеет ли утилита xbps-uchroot(1)
необходимые атрибуты доступа и принадлежности, как описано выше.
proot(1)
Утилита proot(1)
выполняет операции chroot и bind-монтирования полностью в пользовательском пространстве, и может применяться, если ядро системы не поддерживает namespaces. См. http://proot.me для получения дополнительной информации. Для её включения нужно:
$ cd void-packages $ echo XBPS_CHROOT_CMD=proot >> etc/conf
Быстрая установка в Void’е
Клонировать git-репозиторий void-packages и установить bootstrap-пакеты:
$ git clone git://github.com/voidlinux/void-packages.git $ cd void-packages $ ./xbps-src binary-bootstrap
Ввести
$ ./xbps-src -h
чтобы увидеть все доступные цели и опции, и начать собирать любой доступный пакет в каталоге srcpkgs
.
Установка пакетов bootstrap
Пакеты bootstrap
представляют собой набор инструментов, необходимых для сборки любого доступного в исходниках пакета внутри изолированного окружения. Есть два способа установки bootstrap
:
bootstrap
: все его пакеты будут построены с нуля; для чего в хост-системе требуются такие инструменты, какbinutils
,gcc
,perl
,texinfo
, и так далее;binary-bootstrap
: его бинарные пакеты загружаются из репозитория XBPS.
В целях экономии времени лучше использовать binary-bootstrap
.
Конфигурирование
Файл etc/defaults.conf
содержит все параметры, которые переопределять умолчальные настройки утилиты xpbs-src
; если он не существует, настройки берутся из файла ~/.xbps-src.conf
.
Для переопределения флагов компиляции CFLAGS
, CXXFLAGS
и LDFLAGS
, не переписывающих их значения в etc/defaults.conf
, они вносятся в etc/conf
:
$ echo 'XBPS_CFLAGS="your flags here"' >> etc/conf $ echo 'XBPS_LDFLAGS="your flags here"' >> etc/conf
Флаги компиляции и линковки, нативные и кросс-платформенные, устанавливаются указанием архитектуры в файлах common/build-profiles
и common/cross-profiles
, соответственно. По идее они являются достаточно хорошими по умолчанию, и нет необходимости устанавливать их самостоятельно без веских причин.
Виртуальные пакеты
Файл etc/defaults.virtual
содержит подстановки для виртуальных пакетов, используемых как зависимости в дереве пакетов исходных тестов.
Для кастомизации этих подстановок следует скопировать etc/defaults.virtual
в etc/virtual
и отредактировать последний по потребностям.
Иерархия каталогов
В умолчальном конфигурационном файле используется такая иерархия каталогов:
/void-packages |- common |- etc |- srcpkgs | |- xbps | |- template | |- hostdir | |- binpkgs ... | |- ccache-... | |- distcc- ... | |- repocache ... | |- sources ... | |- masterdir | |- builddir -> ... | |- destdir -> ... | |- host -> bind mounted from | |- void-packages -> bind mounted from
Ниже даётся описание этих каталогов:
masterdir
: мастер каталог будет использоваться в качестве корневой файловой системы, для сборки и установки пакетов.builddir
: предназначен для распаковки тарбаллов исходников и сборки пакетов;destdir
: предназначен для установки пакетов, также именуется ложнымdestdir
;hostdir/ccache
: для хранения данныхccache
, включена если опцияXBPS_CCACHE
;hostdir/distcc-[arch]
: для хранения данныхdistcc
, если включена опцияXBPS_DISTCC
;hostdir/repocache
: для хранения бинарных пакетов из удаленных репозиториев;hostdir/sources
: для хранения исходников пакетов;hostdir/binpkgs
: локальный репозиторий для размещения собранных бинарных пакетов.
Сборка пакетов
Простейшая форма сборки пакета:
$ cd void-packages $ ./xbps-src pkg [pkgname]
Когда пакет и его зависимости будут собраны, создаются бинарные пакеты, которые регистрируются в локальном репозитории по умолчанию — hostdir/binpkgs
; путь к локальному репозиторию может быть добавлен в один из файлов конфигурации xbps
или явно указан в командной строке (при необходимости):
$ xbps-install --repository=hostdir/binpkgs ... $ xbps-query --repository=hostdir/binpkgs ...
По умолчанию xbps-src
разрешает зависимости в следующем порядке:
- сначала — в локальном репозитории
hostdir/binpkgs
- затем — в удалённом репозитории;
- наконец, среди исходных текстов.
Чтобы избежать поиска в удалённых репозиториях вообще, используется флаг -N
. Локальный репозиторий может содержать несколько субрепозиториев: debug
, multilib
и так далее.
Опции сборки
Поддерживаемые опции сборки для пакета исходников могут быть выведены так:
$ ./xbps-src show-options foo
Опции сборки для xbps-src
можно подключить указанием флага -o [опция]
:
$ ./xbps-src -o option,option1 pkg foo
Опции сборки могут быть отключены с помощью префикса ~
:
$ ./xbps-src -o ~option,~option1 pkg foo
$ ./xbps-src -o option,~option1,~option2 pkg foo
Оба способа могут использоваться совместно для включения и/или отключения нескольких опций xbps-src
одновременно:
$ ./xbps-src -o option,~option1 pkg foo
Опции сборки для бинарного пакета могут быть выведены при запросе через xbps-query(1)
:
$ xbps-query -R --property=build-options foo
Примечание: если пакет собирается с собственными опциями, и этот пакет доступен в официальном репозитории Void, при обновлении системы эти опции пропадут. Во избежание этого следует зафиксировать пакет с помощью
xbps-pkgdb(1)
, то естьxbps-pkgdb -m hold foo
, чтобы он пропускался при обновлении системы черезxbps-install -u
. Единственный способ обновить пакет в режиме фиксации — явным образом дать командуxbps-install -u foo
.
Глобальные опции сборки могут быть установлены перманентно заданием переменной XBPS_PKG_OPTIONS
в файле конфигурации etc/conf
. Для пакета они устанавливаются переменной XBPS_PKG_OPTIONS_[pkgname]
.
Примечание: если в имени пакета содержатся дефисы, они должны заменяться символами подчёркивания, то есть:
XBPS_PKG_OPTIONS_xorg_server=opt
.
Список поддерживаемых пакетом опций сборки и их описание объявляются в файле common/options.description
или в файле шаблона.
Локальный репозиторий: доступ и подпись
Чтобы сделать локальный репозиторий удалённо доступным, он и его пакеты должны содержать подпись. Это делается с помощью утилиты xbps-rindex(1)
. Первый шаг — создание RSA key с помощью openssl(1)
или ssh-keygen(1)
:
$ openssl genrsa -des3 -out privkey.pem 4096
или
$ ssh-keygen -t rsa -b 4096 -f privkey.pem
В настоящее время
xbps
принимает RSA-ключи только в формате PEM.
После создания приватного RSA-ключа его можно использовать для инициализации метаданных репозитория:
$ xbps-rindex --sign --signedby "I'm Groot" --privkey privkey.pem $PWD/hostdir/binpkgs
А затем поставить подпись на каждый пакет:
$ xbps-rindex --sign-pkg --privkey privkey.pem $PWD/hostdir/binpkgs/*.xbps
Если
--privkey
не установлен, по умолчанию используется~/.ssh/id_rsa
.
Если ключ RSA защищён паролем, его потребуется ввести. Или, альтернативно, установить с помощью переменной среды XBPS_PASSPHRASE
.
После подписания пакетов нужно проверить, содержит ли репозиторий соответствующий hex fingerprint
:
$ xbps-query --repository=hostdir/binpkgs -vL ...
Каждый раз после создания бинарного пакета его потребуется подписать с помощью --sign-pkg
.
Подписать репозиторий несколькими RSA-ключами невозможно.
Пересборка и перезапись существующих локальных пакетов
Если пакет был собран и сделан доступным в локальном репозитории, а затем потребовалось его пересобрать без изменения полей version
или revision
, это легко сделать через xbps-src
:
$ ./xbps-src -f pkg xbps
Переустановку пакета в целевой rootdir
выполнить также легко:
$ xbps-install --repository=/path/to/local/repo -yff xbps-0.25_1
Учтите, что
package expression
должен быть указан явным образом для желаемого репозитория.
Включение distcc для компиляции
Настройка слейва (машины, для которой будет компилироваться код):
# echo "192.168.2.0/24" >> /etc/distcc/clients.allow
Включение и запуск сервиса distcc
:
# ln -s /etc/sv/distccd /var/service
Также надо установить distcc
на хосте (машине, на которой выполняется xbps-src
). Если не требуется использовать хост как слейв для других машин, изменять конфигурацию не нужно.
На хосте можно включить distcc
в конфиге void-packages/etc/conf
:
XBPS_DISTCC=yes XBPS_DISTCC_HOSTS="localhost/2 --localslots_cpp=24 192.168.2.101/9 192.168.2.102/2" XBPS_MAKEJOBS=16
Это примерные значения для локалхоста с процессором с 4 ядрами, из которых два используется для задач компилирования. Количество слотов для задач препроцессора устанавливается равным 24 для того, чтобы иметь достаточно предобработанных данных для компиляции на других процессорах. Слейв 192.168.2.101
имеет процессор с 8 ядрами и /9
— количество задач для избыточности выбора. Для слейва 192.168.2.102
устанавливается две задачи компилирования, чтобы снизить нагрузку на процессор, даже если он имеет 4 ядра. Переменной XBPS_MAKEJOBS
придаётся значение 16, для учёта возможного параллелизма (2 + 9 + 2 + некоторый запас).
Зеркала distfiles
В etc/conf
можно дополнительно определить зеркала для поиска исходников distfiles
:
$ echo 'XBPS_DISTFILES_MIRROR="ftp://192.168.100.5/gentoo/distfiles"' >> etc/conf
Если требуется искать более чем на одном зеркале, в строке можно задать несколько URL, разделённых пробелами. Или добавить зеркало в значения переменной так:
$ echo 'XBPS_DISTFILES_MIRROR+=" http://repo.voidlinux.de/distfiles"' >> etc/conf
В последнем случае не забудьте пробел после первой двойной кавычки.
Зеркала ищутся в порядке дистфайлов для построения пакета, до соответствия контрольной суммы той, что задана в шаблоне.
В конце концов, если зеркало не несёт нужных дистфайлов, или если контрольные суммы не проходят проверку,используется оригинальный репозиторий.
Если в переменной XBPS_CHROOT_CMD
используется proot
или uchroot
, с помощью префикса file://
можно задать локальный путь, или просто указать абсолютный путь на сборочном хосте (например, /mnt/distfiles
). Зеркала, заданные таким образом, будут bind-монтированы в окружении chroot в точке, определяемой $XBPS_MASTERDIR
, и будут искаться так же, как и удалённые источники.
Кросс-компиляция пакетов
В настоящее время xbps-src
может выполнять кросс-компиляцию для нескольких целевых архитектур, которые выводятся командой ./xbps-src -h
.
Если пакет исходников был адаптирован для кросс-компиляции, xbps-src
автоматически соберёт бинарный пакет (или пакеты) простой командой:
$ ./xbps-src -a [target] pkg [pkgname]
Если сборка по какой-либо причине не удаётся — возможно, что пакет не был адаптирован для кросс-компиляции.
Использование xbps-src в иных дистрибутивах Linux
xbps-src
может быть использован в любом современном дистрибутиве Linux при соответствии архитектуры процессора. Для этого нужно следовать приведённым инструкциям. Для начала — скачать статически скомпилированные бинарники xbps
:
$ wget http://repo.voidlinux.eu/static/xbps-static-latest.[arch]-musl.tar.xz $ mkdir ~/XBPS $ tar xvf xbps-static-latest.[arch].tar.xz -C ~/XBPS $ export PATH=~/XBPS/usr/bin:$PATH
Если система не поддерживает пользовательское пространство имён (user namespaces), пользователь должен принадлежать к группе с соответствующими правами (по умолчанию xbuilder
) для доступа к xbps-uchroot(1)
, что делается так
# chown root:[group] ~/XBPS/usr/bin/xbps-uchroot.static # chmod 4750 ~/XBPS/usr/bin/xbps-uchroot.static
Затем нужно клонировать git-репозиторий void-packages
:
$ git clone git://github.com/voidlinux/void-packages
и xbps-src
будет полностью функциональные, нужно только просто запустить bootstrap:
$ ./xbps-src binary-bootstrap
Мастер-каталог создаётся в текущем рабочем каталоге, то есть это будет void-packages/masterdir
.
Изменение мастер-каталога
Если по какой-то причине требуется обновить xbps-src
, и цели bootstrap-update
оказывается недостаточно, можно пересоздать мастер-каталог двумя простыми командами (при этом zap
оставляет в неприкосновенности существующие каталоги ccache
, distcc
и host
):
$ ./xbps-src zap $ ./xbps-src binary-bootstrap
Поддержка обновления мастер-каталога
Иногда пакет bootstrap должны быть обновлены до последней версии, доступной в репозитории, это делается указанием соответствующей цели:
$ ./xbps-src bootstrap-update
Сборка 32-битных пакетов в системе x86_64
Есть два способа сборки 32-битных пакетов на в системах x86_64:
- режим кросс-компиляции;
- нативный режим с 32-битным мастер-каталогом.
Первый режим очень прост:
$ ./xbps-src -a i686 pkg ...
Нативный режим требует создания нового мастер-каталога x86
:
$ ./xbps-src -m masterdir-x86 binary-bootstrap i686 $ ./xbps-src -m masterdir-x86 ...
Сборка нативных пакетов с библиотекой musl C
Нативное сборочное окружение требуется для кросс-компиляции bootstrap-пакетов для библиотеки musl C. Оно создаётся путём установки соответствующего binary-bootstrap
:
$ ./xbps-src binary-bootstrap
Теперь выполняется кросс-компиляция base-chroot-musl
для имеющейся нативной архитектуры:
$ ./xbps-src -a x86_64-musl pkg base-chroot-musl
Теперь нужно подождать, пока все пакеты будут собраны, а потом создать новый мастер-каталог для пакетов musl
:
$ ./xbps-src -m masterdir-x86_64-musl binary-bootstrap x86_64-musl
Новый мастер-каталог готов для сборки нативных пакетов с библиотекой musl C. Выполнить
$ ./xbps-src -m masterdir-x86_64-musl chroot $ ldd
для проверки, работает ли динамическая линковка musl C как надо.
Сборка базовой системы Void с нуля
Пересборка всех пакетов в базовой системе для «родной» архитектуры:
$ ./xbps-src -N pkg base-system
Можно также осуществить кросс-компиляцию с нуля:
$ ./xbps-src -a [target] -N pkg base-system
После завершения сборки можно указать путь к локальному репозиторию для void-mklive
:
# cd void-mklive # make # ./mklive.sh ... -r /path/to/hostdir/binpkgs
Содействие
См. страницу Содействие на предмет внесения своего вклада в общее дело, и страницу The XBPS source packages manual для выяснения деталей создания пакетов исходников.