Опубликовано Автор: alv

Void Linux. XBPS: коллекция исходников пакетов (перевод)

Автор: Хуан Ромеро Пардинес (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 для выяснения деталей создания пакетов исходников.

Оглавление

Добавить комментарий