Void linux install package

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.

Источник

XBPS Package Manager

The X Binary Package System (XBPS) is a fast package manager that has been designed and implemented from scratch. XBPS is managed by the Void Linux team and developed at https://github.com/void-linux/xbps.

Most general package management is done with the following commands:

• xbps-query(1) searches for and displays information about packages installed locally, or, if used with the -R flag, packages contained in repositories.
• xbps-install(1) installs and updates packages, and syncs repository indexes.
• xbps-remove(1) removes installed packages, and can also remove orphaned packages and cached package files.
• xbps-reconfigure(1) runs the configuration steps for installed packages, and can be used to reconfigure certain packages after changes in their configuration files. The latter usually requires the —force flag.
• xbps-alternatives(1) lists or sets the alternatives provided by installed packages. Alternatives is a system which allows multiple packages to provide common functionality through otherwise conflicting files, by creating symlinks from the common paths to package-specific versions that are selected by the user.
• xbps-pkgdb(1) can report and fix issues in the package database, as well as modify it.
• xbps-rindex(1) manages local binary package repositories.

Most questions can be answered by consulting the man pages for these tools, together with the xbps.d(5) man page.

To learn how to build packages from source, refer to the README for the void-packages repository.

Updating

Like any other system, it is important to keep Void up-to-date. Use xbps-install(1) to update:

XBPS must use a separate transaction to update itself. If your update includes the xbps package, you will need to run the above command a second time to apply the rest of the updates.

Restarting Services

XBPS does not restart services when they are updated. This task is left to the administrator, so they can orchestrate maintenance windows, ensure reasonable backup capacity, and generally be present for service upgrades.

To find processes running different versions than are present on disk, use the xcheckrestart tool provided by the xtools package:

xcheckrestart will print out the PID, path to the executable, status of the path that was launched (almost always deleted ) and the process name.

xcheckrestart can and should be run as an unprivileged user.

Kernel Panic After Update

If you get a kernel panic after an update, it is likely your system ran out of space in /boot . Refer to «Removing old kernels» for further information.

Finding Files and Packages

To search available repositories for packages, use xbps-query(1):

The -R flag specifies that repositories should be searched. Without it, -s searches for locally-installed packages.

If you can’t find a file or program you expected to find after installing a package, you can use xbps-query(1) to list the files provided by that package:

The xtools package contains the xlocate(1) utility. xlocate works like locate(1), but for files in the Void package repositories:

It is also possible to use xbps-query(1) to find files, though this is strongly discouraged:

This requires xbps-query to download parts of every package to find the file. xlocate , however, queries a locally cached index of all files, so no network access is required.

To get a list of all installed packages, without their version:

Источник

Void linux install package

All live images and rootfs tarballs are available at:

These files can also be downloaded from other mirrors, which are listed in the documentation. Simply navigate to live -> current to find them.

The requirements for these images can be found in the documentation. An internet connection via Ethernet or WiFi is required for network installation.

Verifying file integrity and its digital signature

It is strongly recommended to validate the integrity and authenticity of any downloaded image or tarball before using it, to ensure it hasn’t been tampered with. Instructions on how to do that are provided in the Void Handbook.

x86_64

Installable live images support a local installation (with the included packages) or a network installation (packages are downloaded from official repository).

You can log into these images as anon or root , and the password is voidlinux .

To start the installer, execute the void-installer utility with appropriate permissions (i.e., sudo void-installer ).

enlightenment

cinnamon

Installable live images support a local installation (with the included packages) or a network installation (packages are downloaded from official repository).

You can log into these images as anon or root , and the password is voidlinux .

To start the installer, execute the void-installer utility with appropriate permissions (i.e., sudo void-installer ).

enlightenment

cinnamon

ROOTFS tarballs can be extracted to a previously prepared partition scheme or used for chroot installation.

General and platform specific instructions are available in the documentation.

armv6l

armv7l

aarch64

arm platforms

Live images can be written onto an SD card (i.e. using dd ) and they provide you with a ready to boot system. These images are prepared for 2GB SD cards. Alternatively, use the ROOTFS tarballs if you want to customize the partitions and filesystems.

Connect to the system using a virtual terminal or SSH and log in as root with password voidlinux .

Platform specific instructions for these images are available in the documentation.

Deprecated instructions for the following platforms can be found in these wiki pages (you can help by porting them over to the Void Handbook):

Источник

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. А эта система будет стоять единственной и заглянуть будет некуда. Т. к. второго ПК или параллельно установленной системы не будет.

Источник