xbps-src — локальная сборка пакетов для Void Linux

1. Что такое xbps-src
2. Папки и файлы
3. Настройки
4. Плюсы и минусы локальной сборки
5. Список готовых (известных мне) шаблонов сборки
6. Вывод

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Одной из отличительных черт Void Linux является возможность локальной сборки пакетов, сочетая их с заводскими бинарниками. Собирать можно все пакеты или только желаемые. Ниже я постарался в этом во всём (или не во всём) разобраться и описать понятным, а не техническим языком, который могут понять не только лишь все инженеры. С официальной информацией можете ознакомиться на странице GitHub.

XBPS-SRC

xbps-src — это утилита для сборки бинарных пакетов XBPS из исходного кода, которая является неотъемлемой частью системы управления пакетами Void Linux. Она работает как скрипт на Bash, позволяя получать исходные тексты программ, компилировать их в изолированной среде (chroot) и создавать готовые бинарные пакеты.

Ключевые особенности и принципы работы xbps-src:

• Механизм сборки: утилита создает изолированную среду с использованием namespaces (пространств имен) или chroot, что позволяет выполнять сборку без необходимости прав root и гарантирует чистоту процесса, отсутствие конфликтов с хост-системой.
• Гибкость конфигурации: позволяет настраивать флаги компиляции (CFLAGS, LDFLAGS), опции сборки и изменять шаблоны пакетов через файлы etc/conf (пользовательские) и etc/defaults.conf (по умолчанию).

• Шаблоны пакетов: процесс опирается на файлы-шаблоны (template), аналогичные PKGBUILD в Arch Linux, которые содержат инструкции по получению исходников, настройке и установке. Эти шаблоны хранятся в репозитории GitHub void-linux/void-packages, в других репозиториях или можно написать самому.

• Инициализация: для начала работы необходимо клонировать репозиторий void-packages и выполнить инициализацию с помощью команды ./xbps-src binary-bootstrap, которая загружает необходимые бинарные пакеты-заготовки.

• Ограниченные пакеты: для сборки пакетов, содержащих проприетарный код или требующих ограничений по лицензии, необходимо явно разрешить это в конфигурационном файле etc/conf, установив переменную XBPS_ALLOW_RESTRICTED=yes

Инструмент поддерживает нативную сборку и кросс-компиляцию для различных архитектур, а также работу с разными реализациями C-библиотек: musl и GNU libc.

Структура каталога

srcpkgs — содержит сценарии сборки ПО, найденные шаблоны или написанные самостоятельно.

etc — настройки для сборки.

hostdir — рабочая директория для xbps-src, в которой хранятся все данные, связанные со сборкой пакетов.

1. В binpkgs помещаются собранные пакеты;
2. sources хранит скачанные исходные коды (архивы, патчи) для всех собираемых пакетов;
3. В repocache накапливается кэш во время операций;
4. С ccache понятно по названию, если пакет установлен и включен в настройках;
5. В cargo и gocache-glibc кэш при сборке Rust и Go. 

xbps-src — скрипт, который выполняет работу по компиляции пакетов, автоматически подхватывая сценарий из srcpkgs, обрабатывает зависимости и создает бинарный пакет в локальном репозитории hostdir/binpkgs. Для запуска команда

./xbps-src pkg [имя_пакета]

У этого скрипта есть неприятность — он собирает только базовый пакет, игнорируя зависимости, поэтому те подтягиваются из репозитория при установке в виде готовых бинарников. Для решения можно использовать команду с ключом -N.

./xbps-src -N pkg [имя_пакета]

Флаг -N в команде заставляет систему собирать все зависимости из исходников, если их бинарные версии отсутствуют в локальном репозитории hostdir/binpkgs.

Если под бинарный пакет зависимости уже существует в hostdir/binpkgs, xbps-src использует его, даже с флагом -N. Это поведение ускоряет сборку и не гарантирует полную пересборку всего стека.

К сожалению, во время написания у меня процесс зависал при загрузке bzip2-1.0.8.tar.gz. Проблема, как я понимаю, на стороне регуляторов, потому что через браузер архив скачивается, вéсит он всего 791 КБ. Смена зеркал мне не помогла. Заметил, что каждая попытка добавляла 1-2 % к прогрессу скачивания, так я выкачал пакет целиком, после процесс пошёл дальше.

С этой манией к пересборке всего и вся я столкнулся с проблемой — у меня теперь не идёт процесс дальше, пока я не пересоберу зависимости. Не знаю, баг это или фича … Вот для примера ниже скриншот с ошибкой при сборке ядра linux6.18. Для установки пакета мне теперь нужно предварительно собрать все пакеты после знака 
=> 
Конкретно это ядро у меня вообще отказывается собираться (патч) даже при всех собранных пакетах сопуствующих, поэтому установил бинарником из общего репозитория.

Параметры

defaults.conf — файл конфигурации по умолчанию для xbps-src.

conf — файл для пользовательских настроек.

• Флаги компиляции: чтобы переопределить флаги CFLAGS, CXXFLAGS или LDFLAGS без изменения файла по умолчанию, добавьте их в etc/conf

• Разрешение сборки «ограниченных» пакетов: для сборки пакетов с проприетарным кодом (например, nvidia)

• Выбор утилиты chroot: для использования xbps-uchroot (требует настройки прав)

defaults.virtual определяет стандартные сопоставления виртуальных пакетов с реальными пакетами. Для изменения поведения нужно создать собственный файл etc/virtual, который будет переопределять настройки из defaults.virtual.

xbps-uchroot использует Linux-пространства имён (namespaces) для изоляции процессов, монтирования и IPC, что безопаснее, чем классический chroot. В отличие от xbps-uunshare (по умолчанию), xbps-uchroot требует setgid-бит и чтобы пользователь был в группе xbuilder, но может работать в средах, где uunshare не поддерживается.

В контексте локальной сборки это нужно для:

• Безопасности: запуск сборки без прав суперпользователя, изолируя процесс в chroot-окружении с помощью Linux-пространств имён.
• Совместимости: использование uchroot может быть необходимо, если стандартный uunshare не работает на вашей системе (например, из-за ограничений ядра).
• Контроля: позволяет явно задать метод изоляции, используемый при сборке пакетов.

Параметр XBPS_CHROOT_CMD определяет утилиту, используемую xbps-src для создания изолированной среды (chroot) при сборке пакетов.

• uunshare (по умолчанию): использует пользовательские пространства имён ядра Linux. Не требует прав root.

• uchroot: также использует пространства имён, но требует, чтобы исполняемый файл был setgid и пользователь был в группе xbuilder.

• proot: реализует chroot в пользовательском пространстве, полезен, если ядро не поддерживает пространства имён.

XBPS_CFLAGS — это переменная окружения в системе сборки xbps-src для Void Linux, которая определяет флаги компилятора C (CFLAGS), используемые при сборке всех пакетов.

По умолчанию, как указано в файле etc/defaults.conf, она установлена в «-O2 -pipe», что означает оптимизацию кода на уровне 2 и использование конвейера для повышения производительности. Эту переменную можно переопределить в пользовательском конфигурационном файле etc/conf, чтобы применить свои флаги оптимизации или отладки для всей системы.

Переменная XBPS_CFLAGS может содержать любые допустимые флаги компилятора GCC/Clang, которые используются для настройки оптимизации, целевой архитектуры и отладки.

Уровни оптимизации:

• -O2 — стандартный баланс производительности и времени компиляции (по умолчанию).
• -O3 — агрессивная оптимизация (может увеличить размер бинарника).
• -Os — оптимизация по размеру бинарника.
• -O0 — отключение оптимизации (для отладки).

Оптимизация под архитектуру:

• -march=native — оптимизировать код под конкретный процессор, на котором идет сборка.
• -mtune=generic — оптимизировать для широкого спектра процессоров одной архитектуры.

Значение архитектуры можно взять из справочника Gentoo или оставить «native»

Другие важные флаги:

• -pipe  — использовать каналы вместо временных файлов для ускорения сборки.
• -flto — включить Link Time Optimization (LTO) для межмодульной оптимизации.
• -g — добавить отладочную информацию.
• -fPIC — генерировать позиционно-независимый код (часто требуется для библиотек).а

Примеры:

• Стандартный (по умолчанию): XBPS_CFLAGS="-O2 -pipe"
• С оптимизацией под процессор и LTO: XBPS_CFLAGS+="-march=native -flto"
• С отладочной информацией: XBPS_CFLAGS+="-g -O0"

XBPS_LDFLAGS — это переменная окружения в системе сборки xbps-src для Void Linux, которая определяет флаги компоновщика (linker flags), используемые при сборке всех пакетов.

-Wl, --as-needed: это ключевой флаг. Префикс -Wl, означает, что следующую опцию нужно передать компоновщику (linker). Сам флаг --as-needed указывает компоновщику связывать только те библиотеки, которые действительно используются исполняемым файлом или библиотекой. Это уменьшает количество зависимостей, ускоряет запуск программ и снижает риск проблем при обновлении библиотек.

-Wl, -O1: Указывает компоновщику выполнить базовую оптимизацию. Это может включать в себя оптимизацию порядка секций для более быстрой загрузки

-z,relro -z,now: делает таблицы GOT/PLT read-only, защищая от перезаписи (Full RELRO).

-z,noexecstack: помечает стек как непригодный для выполнения кода (NX bit).

Эти флаги являются стандартом безопасности для современных дистрибутивов. Они являются утилитарными, значительно повышают защиту от эксплойтов, при этом совместимы с подавляющим большинством программ.

Пример моего содержимого.

# Разрешение сборки пакетов с ограниченным доступом (nonfree, restricted)
XBPS_ALLOW_RESTRICTED=yes

# Включение ccache для ускорения повторных сборок (особенно для C/C++)
XBPS_CCACHE=yes

# Указание альтернативного зеркала для загрузки зависимостей
# XBPS_MIRROR=https://repo-us.voidlinux.org/current

# Выбор метода chroot (по умолчанию uunshare)
# XBPS_CHROOT_CMD=uchroot

# Количество рабочий процессов (ядер/потоков) 
XBPS_MAKEJOBS=8

# Флаги компиляции 
XBPS_CFLAGS="-march=native -O2 -pipe"
XBPS_CXXFLAGS="$XBPS_CFLAGS"
XBPS_CPPFLAGS="$XBPS_CFLAGS"
XBPS_LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack"


# Глобально включить/отключить опции (например, GUI, X11)
#XBPS_PKG_OPTIONS="option,~debug"

# Для конкретного пакета (дефисы заменяются на подчёркивания)
#XBPS_PKG_OPTIONS_xorg_server="glamor,~vgahw"

# Копирование локального кэша пакетов для ускорения загрузки зависимостей
# (полезно при частых сборках)
# Файлы кэша: /var/cache/xbps → hostdir/repocache-$(xbps-uhelper arch)   

# Просмотр опций сборки пакета
#xbps-query -R --property=build-options <package>

# Поиск пакета по файлу (через xlocate из пакета xtools)
#xlocate /usr/include/stdio.h

# Установка собранного пакета через xi (из xtools)
#xi <package-name>

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

Плюсы и минусы самостоятельной сборки

Я рекомендую пересобрать вручную основные компоненты: ядро, Xorg, DM, большие компоненты DE, прикладное ПО — в общем, наиболее тяжёлое, ресурсозатратное и зависимости с ним. Всё это по желанию, разумеется, мне удовольствие доставляет сам процесс, поэтому я собираю и мелкие пакеты.

Для сборки сразу нескольких пакетов нужен скрипт или цикл команд в виде

./xbps-src pkg package1 && ./xbps-src pkg package2 && ./xbps-src pkg package3

Компиляций обновления

Команда ./xbps-src update-sys собирает и обновляет пакеты, установленные в вашей системе, если их версия в локальном репозитории void-packages новее, чем установленная версия. 
Чтобы собрать пакеты с доступными обновлениями, выполните:

#Перейдите в директорию void-packages
cd void-packages

#Обновите репозиторий исходных кодов с помощью git:
git pull

#Используйте команду, чтобы собрать все устаревшие пакеты
./xbps-src update-sys

Важно: update-sys только собирает пакеты, для их фактической установки в систему необходимо выполнить команду

sudo xbps-install --repository=hostdir/binpkgs -u

Команда ./xbps-src update-sys, выполненная вручную из директории void-packages, автоматически соберёт и подготовит к установке все пакеты, для которых в шаблонах репозитория void-packages доступны новые версии. Постепенно так можно собрать почти всю систему. Тут, кстати, кроется плюс бинарной системы: выбирать для сборки можно пакеты по желанию, а нежелательные (с ошибками в процессе или если они долго собираются, ставить заводскими бинарниками).

Я устанавливаю через OctoXBPS (либо через меню Файл поштучно, либо перетащив нужные пакеты на окно)

XBPS_MAKEJOBS

Хочу остановиться на этом параметре подробнее. Если вы собирали локально, например, браузер, ядро, nodejs и другие тяжёлые пакеты, сборка запросто упирается в объём доступной ОЗУ даже у меня (16 ГБ) или в мощности ЦП, к тому же Firefox, по прикидкам, нужно 20-24 ГБ. Для решения этой проблемы можно отключить все приложения, максимум обрезать автозагрузку, но после перезагрузки всё равно памяти не хватит, поэтому желателен ZRam, который я постоянно запускаю. И пришлось ещё вернуться к наличию Swap. Но основным тут является параметр XBPS_MAKEJOBS. Вместе эти ухищрения позволяют собирать громоздкие пакеты на машине с малым объёмом ОЗУ и слабым ЦП.

Переменная XBPS_MAKEJOBS определяет количество параллельных задач при сборке пакетов с помощью make. Значение 4 подходит для процессора с 4 ядрами/потоками, так как оно позволяет эффективно загрузить все ядра. Точное количество ОЗУ, потребляемое одним потоком XBPS_MAKEJOBS, нельзя определить заранее, так как оно сильно варьируется в зависимости от собираемого пакета, используемых флагов компиляции и этапа сборки. Поэтому подбирайте под себя: увеличение числа потоков ускорит сборку за счёт агрессивного использования ресурсов, а низкие значения позволят проводить сборку фоном, продолжая использовать систему для просмотра фильмов и прогулкам по интернету.

Список шаблонов сборки

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

index-0

https://github.com/index-0/void-packages

hazen2215

https://github.com/hazen2215/void-packages

sug0

https://github.com/sug0/voided-packages

visone

https://codeberg.org/visone/void-templates/src/branch/main

xlibre-void

https://github.com/xlibre-void/xlibre

CODJointOps, где есть void-zenkernel

https://github.com/CODJointOps?tab=repositories

vpim (тоже есть XLibre)

https://codeberg.org/RotaryBoot58/vpim

Я отметил лишь некоторые сборники. Если кто-то хочет поделиться интересными вариантами, пишите в комментариях, можно будет добавить. Больше их есть на Github или Codeberg

#voidlinux, #void-packages, #xbps-src, #xbps

Вывод

Самостоятельная компиляция пакетов Void linux — это не тот уровень, который есть в Gentoo based:

1. Пакеты по умолчанию собираются не целиком, лишь целевой, а зависимости бинарниками поставляются; 
2. Да и в целом, насколько я могу судить, система под это не рассчитана, это в качестве бонуса и опционально. Решают ли такие проблемы на форуме, git, IRC и по другим каналам связи, не знаю, мне кажется, что вряд ли; 
3. Нет тонкой настройки а-ля USE флаги, которые позволяют уменьшить число зависимостей или размер пакета можно прописать опции разово и для конкретного пакета (и его версии) либо в файл conf, отчего он распухнет; 
4. Как уже выше писал, мне удовольствие пока что доставляет сам процесс (на уровне изучения и опыта), железо моё позволяет не ужиматься в плане используемого ПО, поэтому радикального ускорения я не заметил. Мне кажется, что прирост есть, но то мне только кажется — когда собираешь в течение времени, привыкается. Если и был прирост, то можно списать на плацебо ¯\_(ツ)_/¯. 

Постарался описать в общих чертах и понятным образом. Если у вас остались вопросы, то прошу к ознакомлению с мануалом, там технические подробности и детали.