Void linux packages search

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:

Источник

Repositories

Repositories are the heart of the XBPS package system. Repositories can be local or remote. A repository contains binary package files, which may have signatures, and a data file named $ARCH-repodata (e.g. x86_64-repodata ), which may also be signed.

Note that, while local repositories do not require signatures, remote repositories must be signed.

The main repository

The locations of the main repository in relation to a base mirror URL are:

• glibc: /current
• musl: /current/musl
• aarch64 and aarch64-musl: /current/aarch64

Subrepositories

In addition to the main repository, which is enabled upon installation, Void provides other official repositories maintained by the Void project, but not enabled by default:

• nonfree: contains software packages with non-free licenses
• multilib: contains 32-bit libraries for 64-bit systems (glibc only)
• multilib/nonfree: contains non-free multilib packages
• debug: contains debugging symbols for packages

These repositories can be enabled via the installation of the relevant package. These packages only install a repository configuration file in /usr/share/xbps.d .

nonfree

Void has a nonfree repository for packages that don’t have free licenses. It can enabled by installing the void-repo-nonfree package.

Packages can end up in the nonfree repository for a number of reasons:

• Non-free licensed software with released source-code.
• Software released only as redistributable binary packages.
• Patented technology, which may or may not have an (otherwise) open implementation.

multilib

The multilib repository provides 32-bit packages as a compatibility layer inside a 64-bit system. It can be enabled by installing the void-repo-multilib package.

These repositories are only available for x86_64 systems running the glibc C library.

multilib/nonfree

The multilib/nonfree repository provides additional 32-bit packages which have non-free licenses. It can be enabled by installing the void-repo-multilib-nonfree package.

debug

Void Linux packages come without debugging symbols. If you want to debug software or look at a core dump you will need the debugging symbols. These packages are contained in the debug repository. It can be enabled by installing the void-repo-debug package.

Once enabled, symbols may be obtained for

Finding debug dependencies

The xtools package contains the xdbg(1) utility to retrieve a list of debug packages, including dependencies, for a package:

Источник

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

Источник

Void linux packages search

The X Binary Package System (in short XBPS) is a binary package system designed and implemented from scratch. Its goal is to be fast, easy to use, bug-free, featureful and portable as much as possible.

The XBPS code is totally compatible with POSIX/SUSv2/C99 standards, and released with a Simplified BSD license (2 clause). There is a well documented API provided by the XBPS Library that is the basis for its frontends to handle binary packages and repositories. Some highlights:

• Supports multiple local/remote repositories (HTTP/HTTPS/FTP).
• RSA signed remote repositories (NEW in 0.27).
• Supports multiple compression formats for repositories: gzip (zlib), bzip2, lz4, xz, zstd (default).
• Supports multiple compression formats for package archives: gzip (zlib), bzip2, lz4, xz, zstd (default).
• SHA256 hashes for package metadata, files and binary packages.
• Supports package states (ala dpkg) to mitigate broken package installs/updates.
• Ability to resume partial package install/updates.
• Ability to unpack only files that have been modified in package updates.
• Ability to use virtual packages.
• Ability to ignore completely any number of packages in dependency resolution.
• Ability to check for incompatible shared libraries in reverse dependencies.
• Ability to update reverse dependencies of any number of packages or globally in a single transaction.
• Ability to replace packages.
• Ability to put packages on hold (to never update them. NEW in 0.16).
• Ability to preserve/update configuration files.
• Ability to force reinstallation of any installed package.
• Ability to downgrade any installed package.
• Ability to execute pre/post install/remove/update scriptlets.
• Ability to check package integrity: missing files, hashes, missing or unresolved (reverse)dependencies, dangling or modified symlinks, etc.

XBPS contains an almost complete test suite, currently with

200 test cases, and its number is growing daily! If you find any issue and you can reproduce it, we will fix it and a new test case will be created. No more regressions!

XBPS is brought to you by:

and many other contributors in the free community that have helped improving it. See the AUTHORS file for a complete list of contributors.

Thanks to all who have contributed.

To build this you’ll need:

• graphviz and doxygen (—enable-api-docs) to build API documentation.
• atf >= 0.15 (—enable-tests) to build the Kyua test suite.

Building and testing for dummies

Thanks to —enable-rpath you can install it anywhere and it will still use the libxbps shared library at $ORIGIN/../lib , that means that if xbps is installed to $HOME/xbps-git/usr , the executables will use $HOME/xbps-git/usr/lib to locate libxbps .

To run the test suite make sure kyua is installed and run the following:

Standard configure script (not generated by GNU autoconf).

By default PREFIX is set /usr/local and may be changed by setting —prefix in the configure script. The DESTDIR variable is also supported at the install stage.

There are some more options that can be tweaked, see them with ./configure —help .

Binaries for Linux compiled statically with the musl C library are available:

These builds are available on all official void mirrors, along with their sha256 checksums.

The xbps package includes the following utilities (among others, not a complete list):

• xbps-create (1) — XBPS utility to create binary packages
• xbps-dgraph (1) — XBPS utility to generate dot(1) graphs
• xbps-install (1) — XBPS utility to install and update packages
• xbps-pkgdb (1) — XBPS utility to report and fix issues in pkgdb
• xbps-query (1) — XBPS utility to query for package and repository information
• xbps-reconfigure (1) — XBPS utility to configure installed packages
• xbps-remove (1) — XBPS utility to remove packages
• xbps-rindex (1) — XBPS utility to handle local binary package repositories

In the following sections there will be a brief description of how these utilities currently work.

In the following examples there will be commands accepting an argument such as

. A package expression is a form to match a pattern; currently XBPS >= 0.19 supports 3 ways to specify them:

by specifying a package name, i.e foo .

by specifying the exact package name and version, i.e foo-1.0_1 .

by specifying a package name and version separated by any of the following version comparators:

• less than
• > greater than
• less or equal than
• >= greater or equal than

Such example would be foo>=2.0 or blah-foo .

Repositories can be declared in a configuration file of the configuration or system configuration directories:

• /xbps.d — The configuration directory (set to /etc/xbps.d )
• /xbps.d — The system directory (set to /usr/share/xbps.d )

A configuration file bearing the same filename in /etc/xbps.d overrides the one from /xbps.d . By default the XBPS package provides only the main Void repository in the /usr/share/xbps.d/00-repository-main.conf file.

Additional repositories can be added by installing any of the following XBPS packages or creating new configuration files manually:

Repositories specified in the configuration directory are added to the head of the list, while repositories specified via system configuration directories are appended to the existing list.

If no repositories are found it’s possible to declare them manually via the command line option —repository , currently accepted in xbps-install(1) and xbps-query(1) .

xbps-query — querying packages and repositories

in local packages. This behaviour can be changed by enabling the -R or —repository option to force repository mode.

To query the list of installed packages:

To query the list of working repositories:

To query the list of installed packages that were installed manually (not as dependencies):

To query the list of packages on hold (won’t be upgraded automatically):

To query the list of installed package orphans (packages that were installed as dependencies but there is not any package currently that requires it):

To query a package and show its meta information:

Additionally the -p or —property option can be used to only show a specific key of a package:

Multiple properties can be specified by delimiting them with commas, i.e -p key,key2 .

To query a package and show its file list:

To query a package and show required run-time dependencies:

To query a package and show required reverse run-time dependencies:

To query for packages matching a file with specified pattern(s) (ownedby mode):

is a shell wildcard pattern as explained in fnmatch(3); e.g «*.png» .

can be specified as arguments.

To query for packages matching pkgname/version/description with specified pattern(s) (search mode):

The same rules explained above in the ownedby mode shall be applied.

xbps-install — installing and updating packages

To synchronize remote repository index files:

The -S, —sync option can be combined while installing or updating packages, i.e xbps-install -Su .

To install a package:

To install multiple packages at once:

To update a single package:

To update all packages (also known as dist-upgrade in Debian/Ubuntu):

The -n, —dry-run option can be used to print what packages will be updated and/or installed and doesn’t need permissions in the target rootdir, which can be useful to list updates.

xbps-remove — removing packages

To remove a package:

To recursively remove unneeded dependencies that were installed by the target package:

To remove package orphans:

To clean the cache directory and remove outdated packages and/or packages with wrong hash:

To remove package orphans and clean the cache repository both options can be combined, i.e xbps-remove -Oo .

xbps-reconfigure — configure (or force configuration of) a package

The xbps-reconfigure(1) utility may be used to configure packages that were not previously (perhaps due to a power outage, process killed, etc) or simply to force package reconfiguration. By default and unless the -f, —force option is set, only packages that were not configured will be processed.

Its usage is simple, specify a package name or a, —all for all packages:

xbps-pkgdb — checking for errors in packages and pkgdb

The xbps-pkgdb(1) utility may be used to check for errors in packages and in the package database. It is also used to update the package database format (if there have been changes). It works exactly the same way as xbps-reconfigure(1) and expects a package name or -a, —all for all packages.

To put a package on hold mode (won’t be upgraded in dist-upgrade mode):

To remove a package from hold mode:

To put a package in automatic mode (as it were installed as a dependency):

To put a package in manual mode (won’t be detected as orphan):

To update the pkgdb format to the latest one:

NOTE: updating the pkgdb format does not happen too frequently, therefore it’s only necessary in rare circumstances.

xbps-rindex — Create, update and administer local repositories

This command only has 3 operation modes:

Add [-a, —all]: adds the specified packages into the specified repository and removes previous entry if found:

The -f, —force option can be used to forcefully register a package into the repository index, even if the same version is already registered.

Clean [-c, —clean]: cleans the index of the specified repository by removing outdated or invalid entries (nonexistent packages, unmatched hashes, etc):

Remove-obsoletes [-r, —remove-obsoletes]: removes obsolete packages in repository (outdated, broken and unmatched hashes):

Upgrade all packages in the system, without asking for an answer:

Clean the cache directory and remove package orphans:

Show information of a package available in repositories:

Show filelist of a package available in repositories:

Find the packages that own the file /bin/ls in repositories:

Make a package keepable (won’t be detected as orphan):

Search for packages in repositories matching the xbps pattern in its pkgver and short_desc objects:

Remove a package and all unnecessary dependencies that were installed:

Appending repositories via command line:

Switch an installed package to on hold mode (won’t be updated via xbps-install -u ):

Switch an installed package to the unhold mode (will be updated if there are updates):

Check for errors on installed packages and in pkgdb:

Источник