Void linux package manager

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)

Источник

Installation

This section includes general information about the process of installing Void. For specific guides, see the «Advanced Installation» section.

Base system requirements

Void can be installed on very minimalist hardware, though we recommend the following minimums for most installations:

Architecture	CPU	RAM	Storage
x86_64-glibc	x86_64	96MB	700MB
x86_64-musl	x86_64	96MB	600MB
i686-glibc	Pentium 4 (SSE2)	96MB	700MB

Note that flavor installations require more resources; how much more depends on the flavor.

Void is not available for the i386, i486, or i586 architectures.

Before installing musl Void, please read the «musl» section of this Handbook, so that you are aware of software incompatibilities.

It is highly recommended to have a network connection available during install to download updates, but this is not required. ISO images contain installation data on-disk and can be installed without network connectivity.

Downloading installation media

The most recent live images and rootfs tarballs can be downloaded from https://alpha.de.repo.voidlinux.org/live/current/. They can also be downloaded from other mirrors. Previous releases can be found under https://alpha.de.repo.voidlinux.org/live/, organized by date.

Verifying images

Each image release’s directory contains two files used to verify the image(s) you download. First, there is a sha256sum.txt file containing image checksums to verify the integrity of the downloaded images. Second is the sha256sum.sig file, used to verify the authenticity of the checksums.

It is necessary to verify both the image’s integrity and authenticity. It is, therefore, recommended that you download both files.

Verifying image integrity

You can verify the integrity of a downloaded file using sha256sum(1) with the sha256sum.txt file downloaded above. The following command will check the integrity of only the image(s) you have downloaded:

This verifies that the image is not corrupt.

Verifying digital signature

Prior to using any image you’re strongly encouraged to validate the signatures on the image to ensure they haven’t been tampered with.

Current images are signed using a signify key that is specific to the release. If you’re on Void already, you can obtain the keys from the void-release-keys package, which will be downloaded using your existing XBPS trust relationship with your mirror. You will also need a copy of signify(1); on Void this is provided by the outils package.

To obtain signify when using a Linux distribution or operating system other than Void Linux:

Install the signify package in Arch Linux and Arch-based distros.
Install the signify-openbsd package in Debian and Debian-based distros.
Install the package listed here for your distribution.
Install signify-osx with homebrew in macOS.

If you can’t obtain signify for some reason (e.g. you are on Windows and can’t use WSL or MinGW), you can use minisign(1) to verify the file.

If you are not currently using Void Linux, it will also be necessary to obtain the appropriate signing key from our Git repository here.

Once you’ve obtained the key, you can verify your image with the sha256sum.sig file. The following example demonstrates the verification of the GCP musl filesystem from the 20191109 release:

If the verification process does not produce the expected «OK» status, do not use it! Please alert the Void Linux team of where you got the image and how you verified it, and we will follow up on it.

For verification with minisign , it is necessary to rename the sha256sum.sig file to sha256sum.txt.minisig and remove the first line from the .pub release key. The following example demonstrates the verification of the sha256sum.txt file from the 20191109 release:

The same warning as above applies. If the verification process isn’t successful, do not use the file — warn the Void Linux team about it.

Источник

Advanced Usage

Downgrading

XBPS allows you to downgrade a package to a specific package version.

Via xdowngrade

The easiest way to downgrade is to use xdowngrade from the xtools package, specifying the package version to which you wish to downgrade:

Via XBPS

XBPS can be used to downgrade to a package version that is no longer available in the repository index.

If the package version had been installed previously, it will be available in /var/cache/xbps/ . If not, it will need to be obtained from elsewhere; for the purposes of this example, it will be assumed that the package version has been added to /var/cache/xbps/ .

First add the package version to your local repository:

Then downgrade with xbps-install :

The -f flag is necessary to force downgrade/re-installation of an already installed package.

Holding packages

To prevent a package from being updated during a system update, use xbps-pkgdb(1):

The hold can be removed with:

Repository-locking packages

If you’ve used xbps-src to build and install a package from a customized template, or with custom build options, you may wish to prevent system updates from replacing that package with a non-customized version. To ensure that a package is only updated from the same repository used to install it, you can repolock it via xbps-pkgdb(1):

To remove the repolock:

Ignoring Packages

Sometimes you may wish to remove a package whose functionality is being provided by another package, but will be unable to do so due to dependency issues. For example, you may wish to use doas(1) instead of sudo(8), but will be unable to remove the sudo package due to it being a dependency of the base-system package. To remove it, you will need to ignore the sudo package.

To ignore a package, add an appropriate ignorepkg entry in an xbps.d(5) configuration file. For example:

You will then be able to remove the sudo package using xbps-remove(1).

Источник

Void Linux. Управление пакетами. Система XBPS: действия с пакетами

Поднабравшись всякой информации о пакетах, пока приступать к действиям с ними — к установке, переустановке, обновлению, удалению и всему, что потребуется впредь.

Как говорилось в позапрошлом очерке, любые действия над пакетами следует начинать с синхронизации репозиториев и локального кеша, поэтому далее опция -S будет фигурировать практически во всех командах. Из которых первая, разумеется, — установка единичного пакета, которая требует только его имени в качестве агремента:

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

Согласие подразумевается по умолчанию, так что тут достаточно нажать Enter. После чего установка происходит со страшной научно-фантастической силой, определяемой, в сущности, только пропусной способностью канала.

Для ообновления пакета или системы в целом предназначена опция -u , и осуществляется оно командами

Существует ещё несколько опций утилиты xbps-install , влияющих на процесс установки:

-f , или —force — принудительная установка более старой версии пакета, нежелеи текущая из репозитория, ули переустановка инсталлированной версии;

-A , или —automatic — при её указании пакеты получают статус автоматически установленных;

-n , или —dry-run — имитация установки с выводом того, какие пакеты будут установлены как зависимости (не требует прав root’а).

Кроме того, есть несколько опций, определяющих установку пакетов из определённых репозиториев. Однако пока у меня они не востребованы: они предназначены в основном для работы с собственными, локальными или удалёнными, репозиториями.

Оборотная стороны установки пакетов — их удаление, которое выполняется утилитой xbps-remove и в простом случае выглядит так:

Что, как и в случае с установкой пакетов, вызовет такое сообщение:

А после согласия — такое:

При этом пакеты, установленные автоматически как зависимости, не затрагиваются, обретая статус «сирот» ( orphan ). Чтобы избавиться от них, команду удаления следует сопроводить опцией -R , или —recursive :

Кроме того, опция -o , или —remove-orphans , служит для очистки системы от «осиротелых» зависимостей. А опция -F , или —force-revdeps , позволяет принудительно удалять пакеты, имеющие обратные зависимости, или так называемые «сломанные» зависимости. Правда, рекомендуется использовать её с осторожностью.

Поскольку при удалении пакетов острожность важнее, чем при установке, команда xbps-remove не обходится и без опции -n , которая позволяет посмотреть последствия деинсталляции какого-либо пакета без вреда для здоровья (системы и своих нервов).

И, наконец, опция -O , или —clean-cache очищает локальный кеш от скачанных пакетов, которые по умолчанию собираются в каталоге /var/cache/xbps . Поскольку, как уже говорилось, Void относится к категории дистрибутивов со «скользящими релизами», и в нём постоянно происходят те или иные обновления, размер этого кеша может быть весьма значительным.

Так, у меня буквально за пару-тройку дней плотного использования этого дистрибутива накапливается до полугигабайта скачанных пакетов. А в силу «скользящего» характера обновлений они очень быстро сменяются обновлёнными версиями, и потому сколько-нибудь длительное время хранить локальный кеш нет ни малейшего резона.

15 комментариев к “ Void Linux. Управление пакетами. Система XBPS: действия с пакетами ”

Опережая паровоз, спрошу — а есть ли у него графический инсталлятор/удалятер?
Консоль, конечно, хорошо, но я за время пользования Линуксом (с 2001 года) так и не проникся к ней любовью (точнее — терпеть ненавижу), хотя и пользую периодически.

Ведь для, скажем, установки чего-нибудь (именно чего-н., т. к. еще не знаю чего, но, например, из игрушек ребенку) консоль категорически не годится. Ибо не знаю — что ставить без описания.

Нет, и, видимо, не предвидится. А описание пакета, найденного при поиске в консоли, будет точно тем же самым, что и в любой графическом инсталляторе, ибо берётся из одного и того же источника — больше ему просто неоткуда браться. Это касается _всех_ пакетных менеджеров, не только XBPS.

Проблема часто в том, что не знаешь, что искать. Просит ребятенок игрушку… Какую-то интересную. В консоли же не узнаешь какие есть и что они из себя представляют. Описания же нет. Или лезть в интернет по поводу ВСЕХ наличествующих в репозитори пакетов?

А ведь можно как-то тут получить в файл список пакетов из репозитория?
Как ТУТ это сделать проще?

И в консольных утилитах систем управления пакетами (повторяю, во _всех_ системах), и в графических «мордах» к ним описание пакета берётся из соответствующего файла (разного в разных системах). А туда оно попадает, как правило, из описания, которое дал своему пакету разработчик — майнтайнеры пакетов себя этим обычно не утруждают. Так что если описание кажется Вам не полным в консольном выводе — оно будет точно таки же и в каком-нибудь Synaptic’е или YaST’е.

> Как ТУТ это сделать проще?
Например, так:
$ xbps -Rs * > all_packages.txt
Но это только из подключённых репозиториев — а по умолчанию он один.
Так что остальные — смотреть в подкаталогах http://repo.voidlinux.eu/current/

Про вывод списка спасибо.
А вот про описание… Да, описание есть, но только если ее (консольку) спросишь про конкретный пакет. А в «мордах» (например, синаптике) можно смотреть/читать подряд или по разделам.

У Вас в описании системы «Dyson как он есть:» есть по этому поводу замечательные слова —
«…может установить графическую надстройку — Synaptic, и в наглядном виде отыскивать остальные требующиеся ему для практической работы компоненты, в том числе пользовательские приложения.»
Вот это я и имел ввиду в процессе своего бурчания.

Дело вкуса, привычек, обстоятельств.
Просто нужно помнить, что описания пакетов будут одни и те же во всех дистрибутивах, системах пакетного менеджмента, консолях и GUI’ях.
Других просто нет 🙂
И в каталогах софта, типа http://zenway.ru/ или http://linsoft.info/ будет то же самое 🙂
Разве что кто сподобится написать подробный материал о той или иной софтине…

Вы или не можете, или отказываетесь понимать. Командой в консоли можно посмотреть о пакете, название которого ты знаешь (как минимум). Невозможно почитать/посмотреть о пакете, которого не знаешь. Тем более, если не знаешь, чего вообще хочешь. Т. е. только о чем-то КОНКРЕТНОМ, а не о чем-то, чего я еще и сам не знаю. Невозможно посмотреть — какие игрушки тут есть для моего 9-тилетнего парня.

PS. Дело не конкретно в игрушках, а в том, что невозможно найти то, чего не знаешь. Просто глянуть — а вдруг я без этого жить не могу? Таким образом я для себя когда-то обнаружил ranger. Сейчас я без него, как без рук.

PPS. Надо по любому поставить. Он мне уже нравится (я про дистрибутив). А дальше — разберемся.

Жаль, что нет возможности исправить/дополнить.
Вдогонку.

PPPS. Спасибо за замечательные статьи. Всегда жду новых.
Пусть не всегда со всем бываю согласен, но всегда читаю с удовольствием.
А побурчать, я думаю, нам с Вами в наши 30 и плюс несколько месяцев позволительно.

Как вариант, можно зайти на сайт (какого-либо поп-дистра) и посмотреть там. Например в Арч, на который данный дистр похож, можно в вики найти описание приложений и к тому же большинство руссифицировано…
Гы-ы-ы, полагаю автору два раза по 30 с хвостиком! ;-D

> Надо по любому поставить. Он мне уже нравится (я про дистрибутив).
Мне тоже 🙂
А по поводу пакетов и их описаний лучший выбор — это таки Linux Mint: доступны все приложения для Ubuntu (включая PPA), есть аналог убунтовского Центра приложений — конечно, без платных коммерческих пакетов, но какой же русский любит покупать софт «на поглядеть», тем более игрушки?
А ещё в Cinnamon (только в реализации для Linux Mint/LMDE) есть бесценная возможность — удалять установленные пакеты прямо из главного меню. Именно пакеты, а не пункты — http://alv.me/?p=8406#toc144
Поскольку обычная судьба пакетов, поставленных «на поглядеть» — быть сразу же удалёнными, штука очень востребованная.

[b]aleks[/b], про «несколько» месяцев… Я имел ввиду именно «несколько». Для меня, например, это 313. Для edf;ftvjuj [b]alv[/b] «чуток» побольше.

Для [b]alv[/b], про Cinnamon я хорошо знаю — сам пользую в LMDE. А эта система будет стоять единственной и заглянуть будет некуда. Т. к. второго ПК или параллельно установленной системы не будет.

Источник