Void linux xbps src

The Void (Linux) distribution

Void is a general purpose operating system, based on the monolithic Linux kernel. Its package system allows you to quickly install, update and remove software; software is provided in binary packages or can be built directly from sources with the help of the XBPS source packages collection.

It is available for a variety of platforms. Software packages can be built natively or cross compiled through the XBPS source packages collection.

Visit the Void build server console for package build status updates.

Contribute to the Void Linux project by adding and updating packages and extending the documentation. More information can be found in the Handbook.

Not a fork!

Void Linux is an independent distribution, developed entirely by volunteers.

Unlike trillions of other existing distros, Void is not a modification of an existing distribution. Void’s package manager and build system have been written from scratch.

Stable rolling release

Void focuses on stability, rather than on being bleeding-edge. Install once, update routinely and safely.

Thanks to our continuous build system, new software is built into binary packages as soon as the changes are pushed to the void-packages repository.

runit

We use runit as the init system and service supervisor.

runit is a simple and effective approach to initialize the system with reliable service supervision. Refer to the Void Handbook for an introduction.

C library diversity

Void Linux supports both the musl and GNU libc implementations, patching incompatible software when necessary and working with upstream developers to improve the correctness and portability of their projects.

xbps is the native system package manager, written from scratch with a 2-clause BSD license.

XBPS allows you to quickly install/update/remove software in your system and features detection of incompatible shared libraries and dependencies while updating or removing packages (among others). Refer to the Handbook for an overview.

xbps-src

xbps-src is the xbps package builder, written from scratch with a 2-clause BSD license.

This builds the software in containers through the use of Linux namespaces, providing isolation of processes and bind mounts (among others). No root required!

Additionally, xbps-src can build natively or cross compile for the target machine, and supports multiple C libraries (glibc and musl currently).

void-packages changes

xbps changes

Recent news

October 03, 2021

US Mirror Retirement

The alpha.us.repo.voidlinux.org mirror has been retired. Users should switch to https://repo-us.voidlinux.org for continued service out of the central US. As part of the switch the US tier one mirror has gained TLS, and is running on a more reliable host.

All contributors with in-flight PRs should rebase to ensure that the latest URL is reflected in your branch’s CI configuration.

September 23, 2021

Hacktoberfest 2021

Are you ready for Hacktoberfest 2021? Void Linux is! We’re excited to be participating for our 5th year. Contributions that help to address our out-of-date packages queue are especially welcome. This is a great way to dip your feet into the world of Linux distro package management and what happens behind the scenes to provide a wide selection of packages and make sure your system remains up to date.

Updating packages is very easy. You can select a package from the list of out of date packages and update it using the tools in the void-packages repo. The manual might be of assistance when you are updating packages.

As a general rule, we recommend that newcommers to the Void Linux project steer clear of “structural” packages unless you have specific domain knowledge that qualifies you to work on high-risk packages. When selecting a package to update, prefer packages registered to orphan@voidlinux.org . These packages are otherwise unmaintained, and your contribution will have a bigger impact. You can update packages that have a maintainer assigned, but understand that conflicting changes between a maintainer and contributor will be resolved at the discretion of Void staff.

Here are some useful tips when updating packages:

While we’re not completely opposed to PRs that add new packages, you’re much more likely to get your PR approved and merged if it’s a well written update.
Don’t PR broken code. Our maintainers are much less likely to give a second look to a PR that didn’t build when it was submitted.
While it’s possible to run xbps-src from an alien distro, this isn’t really supported. If you’re a seasoned Linux user and want to try Void, now is the time!
The update list is sometimes wrong. We’d love to get patches that improve its reliability by ignoring beta versions or adding checks to packages that are not correctly detected as out of date.
If you have expertise in C, GNU Autotools, or other build systems, taking a look at projects that we’ve marked as incompatible with cross compilation and fixing the upstream issue can be an amazing contribution that impacts more than just Void.

We look forward to working with the amazing world of open source developers this month to improve Void and continue our high standards for quality and reliability. To ensure your PR has the best chance at being accepted, feel free to reach out for help as explained in the manual. Together, we can make this a high-impact Hacktoberfest.

Linux® is a registered trademark of Linus Torvalds (info)

Источник

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) , соответственно.

Системные требования

Для работы сценария 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:

Это — метод работы по умолчанию, и если система не поддерживает какую-либо из указанных опций ядра, он не будет выполнен с сообщением EINVAL (Invalid argument).

xbps-uchroot(1)

Эта утилита требует таких опций ядра Linux:

Пользователь должен быть добавлен в специальную группу для использования xbps-uchroot и получить setgid :

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

Если это почему-то вызывает ошибку типа Operation not permitted , следует проверить, является ли пользователем членом нужной группы, и имеет ли утилита xbps-uchroot(1) необходимые атрибуты доступа и принадлежности, как описано выше.

proot(1)

Утилита proot(1) выполняет операции chroot и bind-монтирования полностью в пользовательском пространстве, и может применяться, если ядро системы не поддерживает namespaces. См. http://proot.me для получения дополнительной информации. Для её включения нужно:

Быстрая установка в Void’е

Клонировать git-репозиторий void-packages и установить bootstrap-пакеты:

чтобы увидеть все доступные цели и опции, и начать собирать любой доступный пакет в каталоге srcpkgs .

Читайте также: Archive utility mac os

Установка пакетов bootstrap

Пакеты bootstrap представляют собой набор инструментов, необходимых для сборки любого доступного в исходниках пакета внутри изолированного окружения. Есть два способа установки bootstrap :

bootstrap : все его пакеты будут построены с нуля; для чего в хост-системе требуются такие инструменты, как binutils , gcc , perl , texinfo , и так далее;
binary-bootstrap : его бинарные пакеты загружаются из репозитория XBPS.

В целях экономии времени лучше использовать binary-bootstrap .

Конфигурирование

Файл etc/defaults.conf содержит все параметры, которые переопределять умолчальные настройки утилиты xpbs-src ; если он не существует, настройки берутся из файла

Для переопределения флагов компиляции CFLAGS , CXXFLAGS и LDFLAGS , не переписывающих их значения в etc/defaults.conf , они вносятся в etc/conf :

Флаги компиляции и линковки, нативные и кросс-платформенные, устанавливаются указанием архитектуры в файлах common/build-profiles и common/cross-profiles , соответственно. По идее они являются достаточно хорошими по умолчанию, и нет необходимости устанавливать их самостоятельно без веских причин.

Виртуальные пакеты

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

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

Иерархия каталогов

В умолчальном конфигурационном файле используется такая иерархия каталогов:

Ниже даётся описание этих каталогов:

masterdir : мастер каталог будет использоваться в качестве корневой файловой системы, для сборки и установки пакетов.
builddir : предназначен для распаковки тарбаллов исходников и сборки пакетов;
destdir : предназначен для установки пакетов, также именуется ложным destdir ;
hostdir/ccache : для хранения данных ccache , включена если опция XBPS_CCACHE ;
hostdir/distcc-[arch] : для хранения данных distcc , если включена опция XBPS_DISTCC ;
hostdir/repocache : для хранения бинарных пакетов из удаленных репозиториев;
hostdir/sources : для хранения исходников пакетов;
hostdir/binpkgs : локальный репозиторий для размещения собранных бинарных пакетов.

Сборка пакетов

Простейшая форма сборки пакета:

Когда пакет и его зависимости будут собраны, создаются бинарные пакеты, которые регистрируются в локальном репозитории по умолчанию — hostdir/binpkgs ; путь к локальному репозиторию может быть добавлен в один из файлов конфигурации xbps или явно указан в командной строке (при необходимости):

По умолчанию xbps-src разрешает зависимости в следующем порядке:

сначала — в локальном репозитории hostdir/binpkgs
затем — в удалённом репозитории;
наконец, среди исходных текстов.

Чтобы избежать поиска в удалённых репозиториях вообще, используется флаг -N . Локальный репозиторий может содержать несколько субрепозиториев: debug , multilib и так далее.

Опции сборки

Поддерживаемые опции сборки для пакета исходников могут быть выведены так:

Опции сборки для xbps-src можно подключить указанием флага -o [опция] :

Опции сборки могут быть отключены с помощью префикса

Оба способа могут использоваться совместно для включения и/или отключения нескольких опций xbps-src одновременно:

Опции сборки для бинарного пакета могут быть выведены при запросе через xbps-query(1) :

Примечание: если пакет собирается с собственными опциями, и этот пакет доступен в официальном репозитории 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) :

В настоящее время xbps принимает RSA-ключи только в формате PEM.

После создания приватного RSA-ключа его можно использовать для инициализации метаданных репозитория:

А затем поставить подпись на каждый пакет:

Если —privkey не установлен, по умолчанию используется

Если ключ RSA защищён паролем, его потребуется ввести. Или, альтернативно, установить с помощью переменной среды XBPS_PASSPHRASE .

После подписания пакетов нужно проверить, содержит ли репозиторий соответствующий hex fingerprint :

Каждый раз после создания бинарного пакета его потребуется подписать с помощью —sign-pkg .

Подписать репозиторий несколькими RSA-ключами невозможно.

Пересборка и перезапись существующих локальных пакетов

Если пакет был собран и сделан доступным в локальном репозитории, а затем потребовалось его пересобрать без изменения полей version или revision , это легко сделать через xbps-src :

Переустановку пакета в целевой rootdir выполнить также легко:

Учтите, что package expression должен быть указан явным образом для желаемого репозитория.

Включение distcc для компиляции

Настройка слейва (машины, для которой будет компилироваться код):

Включение и запуск сервиса distcc :

Также надо установить distcc на хосте (машине, на которой выполняется xbps-src ). Если не требуется использовать хост как слейв для других машин, изменять конфигурацию не нужно.

На хосте можно включить distcc в конфиге void-packages/etc/conf :

Это примерные значения для локалхоста с процессором с 4 ядрами, из которых два используется для задач компилирования. Количество слотов для задач препроцессора устанавливается равным 24 для того, чтобы иметь достаточно предобработанных данных для компиляции на других процессорах. Слейв 192.168.2.101 имеет процессор с 8 ядрами и /9 — количество задач для избыточности выбора. Для слейва 192.168.2.102 устанавливается две задачи компилирования, чтобы снизить нагрузку на процессор, даже если он имеет 4 ядра. Переменной XBPS_MAKEJOBS придаётся значение 16, для учёта возможного параллелизма (2 + 9 + 2 + некоторый запас).

Зеркала distfiles

В etc/conf можно дополнительно определить зеркала для поиска исходников distfiles :

Если требуется искать более чем на одном зеркале, в строке можно задать несколько URL, разделённых пробелами. Или добавить зеркало в значения переменной так:

В последнем случае не забудьте пробел после первой двойной кавычки.

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

В конце концов, если зеркало не несёт нужных дистфайлов, или если контрольные суммы не проходят проверку,используется оригинальный репозиторий.

Если в переменной XBPS_CHROOT_CMD используется proot или uchroot , с помощью префикса file:// можно задать локальный путь, или просто указать абсолютный путь на сборочном хосте (например, /mnt/distfiles ). Зеркала, заданные таким образом, будут bind-монтированы в окружении chroot в точке, определяемой $XBPS_MASTERDIR , и будут искаться так же, как и удалённые источники.

Кросс-компиляция пакетов

В настоящее время xbps-src может выполнять кросс-компиляцию для нескольких целевых архитектур, которые выводятся командой ./xbps-src -h .

Если пакет исходников был адаптирован для кросс-компиляции, xbps-src автоматически соберёт бинарный пакет (или пакеты) простой командой:

Если сборка по какой-либо причине не удаётся — возможно, что пакет не был адаптирован для кросс-компиляции.

Использование xbps-src в иных дистрибутивах Linux

xbps-src может быть использован в любом современном дистрибутиве Linux при соответствии архитектуры процессора. Для этого нужно следовать приведённым инструкциям. Для начала — скачать статически скомпилированные бинарники xbps :

Если система не поддерживает пользовательское пространство имён (user namespaces), пользователь должен принадлежать к группе с соответствующими правами (по умолчанию xbuilder ) для доступа к xbps-uchroot(1) , что делается так

Затем нужно клонировать git-репозиторий void-packages :

и xbps-src будет полностью функциональные, нужно только просто запустить bootstrap:

Мастер-каталог создаётся в текущем рабочем каталоге, то есть это будет void-packages/masterdir .

Изменение мастер-каталога

Если по какой-то причине требуется обновить xbps-src , и цели bootstrap-update оказывается недостаточно, можно пересоздать мастер-каталог двумя простыми командами (при этом zap оставляет в неприкосновенности существующие каталоги ccache , distcc и host ):

Поддержка обновления мастер-каталога

Иногда пакет bootstrap должны быть обновлены до последней версии, доступной в репозитории, это делается указанием соответствующей цели:

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

Есть два способа сборки 32-битных пакетов на в системах x86_64:

режим кросс-компиляции;
нативный режим с 32-битным мастер-каталогом.

Первый режим очень прост:

Нативный режим требует создания нового мастер-каталога x86 :

Сборка нативных пакетов с библиотекой musl C

Нативное сборочное окружение требуется для кросс-компиляции bootstrap-пакетов для библиотеки musl C. Оно создаётся путём установки соответствующего binary-bootstrap :

Теперь выполняется кросс-компиляция base-chroot-musl для имеющейся нативной архитектуры:

Теперь нужно подождать, пока все пакеты будут собраны, а потом создать новый мастер-каталог для пакетов musl :

Новый мастер-каталог готов для сборки нативных пакетов с библиотекой musl C. Выполнить

для проверки, работает ли динамическая линковка musl C как надо.

Сборка базовой системы Void с нуля

Пересборка всех пакетов в базовой системе для «родной» архитектуры:

Можно также осуществить кросс-компиляцию с нуля:

После завершения сборки можно указать путь к локальному репозиторию для void-mklive :

Содействие

См. страницу Содействие на предмет внесения своего вклада в общее дело, и страницу The XBPS source packages manual для выяснения деталей создания пакетов исходников.

Оставьте комментарий Отменить ответ

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

Источник