Рейтинг@Mail.ru

Наши партнеры

UnixForum



Библиотека сайта rus-linux.net

Эволюция менеджеров пакетов в Linux

Оригинал: The evolution of package managers
Автор: Steve Ovens
Дата публикации: 26 июля 2018 года
Перевод: А. Кривошей
Дата перевода: ноябрь 2018 г.

Менеджеры пакетов играют важную роль в системе управления программным обеспечением Linux. В данной статье производится сравнение наиболее популярных игроков на этом рынке.

Каждое компьютеризированное устройство использует для выполнения своих задач некоторую форму программного обеспечения. Давным давно продукты программного обеспечения строго тестировались на наличие ошибок и других дефектов. В течение последнего десятилетия программное обеспечение распространяется через Интернет, подразумевая, чтобы любые найденные ошибки будут исправлены путем выпуска новых версий программного обеспечения. В некоторых случаях каждое отдельное приложение имеет свой собственный модуль обновления. В других случаях пользователю предоставляется возможность выяснить, как получить и обновить программное обеспечение.

В Linux давно введена практика создания централизованного хранилища, где пользователи могут находить и устанавливать программное обеспечение. В этой статье я расскажу об истории установки программ в Linux и о том, как постоянно обновляются современные операционные системы.

Как устанавливались программы в Linux до появления менеджеров пакетов?

Исторически программное обеспечение предоставлялось либо через FTP-серверы, либо в списках рассылки. Только несколько небольших файлов содержали инструкции по созданию двоичного файла (обычно в файле tarfile). Вы должны были распаковать файлы, прочитать readme, и если у вас есть GCC или какой-либо другой компилятор C, вы обычно запускаете скрипт ./configure с некоторым списком атрибутов, например, путями к библиотекам и т. д. Кроме того, процесс configure проверяет вашу систему на наличие зависимостей приложений. Если какие-либо основные требования не выполнены, скрипт configure завершит работу, и вы не сможете продолжить установку до тех пор, пока не будут выполнены все зависимости. Если скрипт configure успешно завершен, будет создан Makefile.

Как только файл Makefile создан, вы должны продолжить, запустив выполнение команды make (эта команда предоставляется любым компилятором, который вы используете). Команда make имеет несколько параметров, называемых make flags, которые помогают оптимизировать результирующие двоичные файлы для вашей системы. Раньше это было очень важно, потому что аппаратное обеспечение изо всех сил старалось не отставать от современных требований к программному обеспечению. Сегодня варианты компиляции могут быть гораздо более универсальными, поскольку большинство аппаратных средств более чем подходит для современного программного обеспечения.

Наконец, после того, как процесс make завершен, вам нужно будет выполнить make install (или sudo make install), чтобы фактически установить программное обеспечение. Как вы можете себе представить, делать это для каждой отдельной программы было трудоемким и утомительным процессом, не говоря уже о том, что обновление программного обеспечения было сложным и потенциально очень рискованным процессом.

Что такое пакет?

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

Несколько проектов Linux разработали свои собственные форматы пакетов. Некоторые из наиболее часто используемых форматов пакетов:

.deb: Этот формат пакета используется Debian, Ubuntu, Linux Mint и многими другими их производными. Это был первый разработанный тип пакета.
.rpm: Этот формат пакета первоначально назывался Red Hat Package Manager. Он используется Red Hat, Fedora, SUSE и другими меньшими дистрибутивами на их базе.
.tar.xz: это просто архив с файлами программы, это формат, который использует Arch Linux.

Хотя сами пакеты напрямую не управляют зависимостями, они представляют собой огромный шаг вперед в управлении программным обеспечением Linux.

Что такое репозиторий программного обеспечения?

Несколько лет назад, до распространения смартфонов, идея создания репозитория программного обеспечения была сложной для многих пользователей, если они не были вовлечены в экосистему Linux. По сей день большинство пользователей Windows по-прежнему используют веб-браузер для поиска и установки нового программного обеспечения. Тем не менее, те, у кого есть смартфоны, привыкли к идее «магазина» программного обеспечения. То, как пользователи смартфонов получают программы, и как работают менеджеры пакетов, не отличается друг от друга. Хотя было несколько попыток создать привлекательный интерфейс для репозиториев программного обеспечения, подавляющее большинство пользователей Linux по-прежнему используют для установки пакетов командную строку. Репозитории программного обеспечения представляют собой централизованный список всех доступных программ для любого репозитория, подключенного к системе. Ниже приведены некоторые примеры поиска репозитория для заданного пакета (обратите внимание, что они были усечены для краткости):

Arch Linux с использованием aurman

Ubuntu с использованием APT

user@ubuntu ~ $ apt search kate
Sorting... Done
Full Text Search... Done

kate/xenial 4:15.12.3-0ubuntu2 amd64
  powerful text editor

kate-data/xenial,xenial 4:4.14.3-0ubuntu4 all
  shared data files for Kate text editor

kate-dbg/xenial 4:15.12.3-0ubuntu2 amd64
  debugging symbols for Kate

kate5-data/xenial,xenial 4:15.12.3-0ubuntu2 all
  shared data files for Kate text editor

Наиболее распространенные менеджеры пакетов.

Как показано в приведенном выше выводе, для взаимодействия с репозиториями программного обеспечения используются менеджеры пакетов. Ниже приведен краткий обзор некоторых из наиболее известных менеджеров пакетов.

Менеджеры пакетов на основе RPM

Обновление систем на основе RPM, особенно тех, которые основаны на технологиях Red Hat, имеет очень интересную историю. Фактически, текущие версии yum (для корпоративных дистрибутивов) и DNF (для сообщества) для обеспечения их текущей функциональности объединяют несколько проектов с открытым исходным кодом.

Первоначально Red Hat использовал диспетчер пакетов RPM (Red Hat Package Manager), который по-прежнему используется и сегодня. Однако его основное назначение заключается в установке пакетов RPM, которые находятся локально на вашем компьютере, а не для поиска репозиториев программного обеспечения. Для информирования пользователей об обновлениях пакетов был создан менеджер пакетов с именем up2date, он позволяет искать удаленные репозитории и легко устанавливать зависимости. В то же время, некоторые члены сообщества считали, что у up2date были некоторые существенные недостатки.

Нынешняя реализация yum произошла из усилий различных частей сообщества. Yellowdog Updater (YUP) был разработан в 1999-2001 годах людьми из Terra Soft Solutions в качестве базового механизма для графического установщика Yellow Dog Linux. Людям из Duke University понравилась идея YUP и они решили улучшить его. Они создали Yellowdog Updater, Modified (yum), который в конечном итоге был адаптирован для управления системами Red Hat Linux в университете. Популярность Yum росла, и к 2005 году он, по различным оценкам, использовался более чем половиной рынка Linux. Сегодня почти во всех дистрибутивах Linux, использующих RPM, для управления пакетами используется yum (с несколькими заметными исключениями).

Работа с yum

Чтобы yum загружал и устанавливал пакеты из интернет-репозиториев, файлы должны быть расположены в /etc/yum.repos.d/, и они должны иметь расширение .repo. Вот пример файла repo:

[local_base]
name=Base CentOS  (local)
baseurl=http://7-repo.apps.home.local/yum-repo/7/
enabled=1
gpgcheck=0

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

Как только файл репозитория на месте, вы можете начать установку пакетов из удаленного репозитория. Основная команда - это yum update, которая обновит каждый установленный пакет. Это не требует отдельного шага для обновления информации о репозиториях; это делается автоматически. Пример команды показан ниже:

[user@centos ~]$ sudo yum update
Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-manager
local_base                             | 3.6 kB  00:00:00     
local_epel                             | 2.9 kB  00:00:00     
local_rpm_forge                        | 1.9 kB  00:00:00     
local_updates                          | 3.4 kB  00:00:00     
spideroak-one-stable                   | 2.9 kB  00:00:00     
zfs                                    | 2.9 kB  00:00:00     
(1/6): local_base/group_gz             | 166 kB  00:00:00     
(2/6): local_updates/primary_db        | 2.7 MB  00:00:00     
(3/6): local_base/primary_db           | 5.9 MB  00:00:00     
(4/6): spideroak-one-stable/primary_db |  12 kB  00:00:00     
(5/6): local_epel/primary_db           | 6.3 MB  00:00:00     
(6/6): zfs/x86_64/primary_db           |  78 kB  00:00:00     
local_rpm_forge/primary_db             | 125 kB  00:00:00     
Determining fastest mirrors
Resolving Dependencies
--> Running transaction check

Если вы уверены, что хотите выполнить любую команду без остановки ввода, вы можете поместить в команду флаг -y, например yum update -y.

Установка нового пакета так же проста. Сначала найдите имя пакета с помощью поиска yum:

[user@centos ~]$ yum search kate

artwiz-aleczapka-kates-fonts.noarch : Kates font in Artwiz family
ghc-highlighting-kate-devel.x86_64 : Haskell highlighting-kate library development files
kate-devel.i686 : Development files for kate
kate-devel.x86_64 : Development files for kate
kate-libs.i686 : Runtime files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.i686 : Kate kpart plugin

После того, как у вас есть имя пакета, вы можете просто установить пакет с помощью команды: sudo yum install kate-devel -y. Если вы установили пакет, который вам больше не нужен, вы можете удалить его с помощью sudo yum remove kate-devel -y. По умолчанию yum удалит пакет и его зависимости.

Бывают случаи, когда вы не знаете имя пакета, но знаете имя утилиты. Например, предположим, что вы ищете утилиту updateb, которая создает/обновляет базу данных, используемую командой locate. Попытка установить updatedb возвращает следующие результаты:

[user@centos ~]$ sudo yum install updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
No package updatedb available.
Error: Nothing to do

Вы можете узнать, из какого пакета работает утилита:

[user@centos ~]$ yum whatprovides *updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile

bacula-director-5.2.13-23.1.el7.x86_64 : Bacula Director files
Repo        : local_base
Matched from:
Filename    : /usr/share/doc/bacula-director-5.2.13/updatedb

mlocate-0.26-8.el7.x86_64 : An utility for finding files by name
Repo        : local_base
Matched from:
Filename    : /usr/bin/updatedb

Причина, по которой я использовал звездочку перед командой, заключается в том, что yum whatprovides использует путь к файлу, чтобы найти совпадение. Поскольку я не был уверен, где находится файл, я использовал звездочку, чтобы указать любой путь.

Есть, конечно, еще много вариантов использования для yum. Я рекомендую вам просмотреть man-страницу yum для изучения дополнительных параметров.

Dandified Yum (DNF) - это новая итерация yum. Представленный в Fedora 18, он еще не принят в промышленных дистрибутивах, и преимущественно используется в Fedora (и ее производных). Его использование почти точно такое же, как у yum, но эта утилита была создана для решения проблем с низкой производительностью, недокументированными API, медленного/неработающего разрешения зависимостей и утечек памяти. DNF представляет собой замену yum, и поэтому я не буду повторять команды - везде, где вы будете использовать yum, просто замените его на dnf.

Работа с Zypper

Zypper - еще один менеджер пакетов, который помогает управлять RPM. Этот менеджер пакетов чаще всего связывают с SUSE (и openSUSE), но он также принят в MeeGo, Sailfish OS и Tizen. Он был первоначально представлен в 2006 году и с тех пор развивается. Zypper используется в качестве бэкенда для инструмента администрирования системы YaST, и некоторые пользователи считают, что он быстрее, чем yum.

Использование Zypper очень похоже на использование yum. Для поиска, обновления, установки или удаления пакета просто используйте следующие команды:

zypper search kate
zypper update
zypper install kate
zypper remove kate

Некоторые существенные различия имеются в том, как с помощью zypper в систему добавляются репозитории. В отличие от описанных выше менеджеров пакетов, zypper добавляет репозитории, используя сам менеджер пакетов. Наиболее распространенным способом является URL-адрес, но zypper также поддерживает импорт из файлов репо.

Аналогично вы можете удалять репозитории:

suse:~ # zypper removerepo vlc
Removing repository 'vlc' ...................................[done]
Repository 'vlc' has been removed.

Используйте команду zypper repos, чтобы узнать статус репозиториев в вашей системе:

suse:~ # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.

#  | Alias                     | Name                                    | Enabled | GPG Check | Refresh
---+---------------------------+-----------------------------------------+---------+-----------+--------
 1 | repo-debug                | openSUSE-Leap-15.0-Debug                | No      | ----      | ----  
 2 | repo-debug-non-oss        | openSUSE-Leap-15.0-Debug-Non-Oss        | No      | ----      | ----  
 3 | repo-debug-update         | openSUSE-Leap-15.0-Update-Debug         | No      | ----      | ----  
 4 | repo-debug-update-non-oss | openSUSE-Leap-15.0-Update-Debug-Non-Oss | No      | ----      | ----  
 5 | repo-non-oss              | openSUSE-Leap-15.0-Non-Oss              | Yes     | ( p) Yes  | Yes    
 6 | repo-oss                  | openSUSE-Leap-15.0-Oss                  | Yes     | ( p) Yes  | Yes    

zypper даже имеет аналогичную способность определять, какой пакет содержит заданные файлы. В отличие от YUM, в команде используется дефис (хотя этот метод поиска устарел):

localhost:~ # zypper what-provides kate
Command 'what-provides' is replaced by 'search --provides --match-exact'.
See 'help search' for all available options.
Loading repository data...
Reading installed packages...

S  | Name | Summary              | Type      
---+------+----------------------+------------
i+ | Kate | Advanced Text Editor | application
i  | kate | Advanced Text Editor | package  

Как и в случае с YUM и DNF, Zypper имеет гораздо более богатый набор функций, чем мы здесь рассказали. Ознакомьтесь с официальной документацией для получения более подробной информации.

Менеджеры пакетов на базе Debian

Один из старейших дистрибутивов Linux, Debian очень похож на системы на основе RPM. Дистрибутивы на его базе используют пакеты .deb, которыми может управлять инструмент dpkg. Сам dpkg очень похож на rpm, поскольку он предназначен для управления пакетами, доступными локально. Он не поддерживает разрешения зависимости (хотя и проверяет их) и не имеет надежного способа взаимодействия с удаленными репозиториями. Чтобы улучшить пользовательский интерфейс и простоту его использования, проект Debian начал разработку системы под кодовым названием Deity. Это кодовое имя в конечном итоге было заменено на Advanced Package Tool (APT).

Тестовая сборка была выпущена в 1998 году (релиз вышел в Debian 2.1 в 1999 году). Многие пользователи считают APT одной из определяющих особенностей систем на базе Debian. Он использует репозитории аналогично системам на основе RPM, но вместо отдельных файлов .repo, которые использует yum, apt исторически использовал файл /etc/apt/sources.list для управления репозиториями. С недавних пор он также использует файлы из /etc/apt/sources.d/. Следуя примерам в менеджерах пакетов на основе RPM, чтобы выполнить ту же задачу в дистрибутивах на базе Debian, у вас есть несколько вариантов. Вы можете редактировать/создавать файлы вручную в вышеупомянутых местах, или в некоторых случаях вы можете использовать графический интерфейс (например, Software & Updates, предоставляемый Ubuntu и др.). Чтобы обеспечить одинаковую работу системы во всех дистрибутивах, я расскажу только о вариантах командной строки. Чтобы добавить репозиторий без прямого редактирования файла, вы можете сделать что-то вроде этого:

user@ubuntu:~$ sudo apt-add-repository "deb http://APT.spideroak.com/ubuntu-spideroak-hardy/ release restricted"

Это создаст файл spideroakone.list в /etc/apt/sources.list.d. Очевидно, эти строки меняются в зависимости от добавляемого репозитория. Если вы добавляете Personal Package Archive (PPA), вы можете сделать это следующим образом:

user@ubuntu:~$ sudo apt-add-repository ppa:gnome-desktop

Примечание: Debian не поддерживает PPA нативно.

После добавления репозитория система на базе Debian должна быть уведомлена о том, что существует новое место для поиска пакетов. Это делается с помощью команды apt-get update:

user@ubuntu:~$ sudo apt-get update
Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 kB]
Hit:2 http://APT.spideroak.com/ubuntu-spideroak-hardy release InRelease
Hit:3 http://ca.archive.ubuntu.com/ubuntu xenial InRelease
Get:4 http://ca.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]              
Get:5 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [517 kB]
Get:6 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages [455 kB]      
Get:7 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [221 kB]    
...

Fetched 6,399 kB in 3s (2,017 kB/s)                                          
Reading package lists... Done

Теперь новый репозиторий добавлен и обновлен, вы можете искать в нем пакеты с помощью команды apt-cache:

user@ubuntu:~$ apt-cache search kate
aterm-ml - Afterstep XVT - a VT102 emulator for the X window system
frescobaldi - Qt4 LilyPond sheet music editor
gitit - Wiki engine backed by a git or darcs filestore
jedit - Plugin-based editor for programmers
kate - powerful text editor
kate-data - shared data files for Kate text editor
kate-dbg - debugging symbols for Kate
katepart - embeddable text editor component

Для установки kate просто запустите соответствующую команду установки:

user@ubuntu:~$ sudo apt-get install kate

Для удаления пакета используйте команду apt-get remove:

user@ubuntu:~$ sudo apt-get remove kate

Когда дело доходит до обнаружения пакетов, APT не предоставляет никаких функций, похожих на yum. Есть несколько способов получить эту информацию, если вы пытаетесь найти, откуда появился конкретный файл на диске.

Используя dpkg:

user@ubuntu:~$ dpkg -S /bin/ls
coreutils: /bin/ls

Используя apt-file:

user@ubuntu:~$ sudo apt-get install apt-file -y

user@ubuntu:~$ sudo apt-file update

user@ubuntu:~$ apt-file search kate

Проблема с поиском apt-file заключается в том, что он, в отличие от yum whatprovides, слишком многословный, если вы не знаете точного пути, и он автоматически добавляет поиск подходящих символов, чтобы вы получили результаты по всему со словом kate в нем:

kate: /usr/bin/kate
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katebacktracebrowserplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katebuildplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katecloseexceptplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katectagsplugin.so

Большинство из этих примеров использовали apt-get. Обратите внимание, что большинство текущих руководств для Ubuntu специально используют просто apt. Команда apt была разработана для реализации только наиболее часто используемых команд в арсенале APT. Поскольку функциональность разделена между apt-get, apt-cache и другими командами, apt пытается объединить их в одну команду. Он также добавил некоторые тонкости, такие как раскраска, индикаторы выполнения и т.д. Большинство упомянутых выше команд можно заменить apt, но не все дистрибутивы на основе Debian поддерживают apt по умолчанию, поэтому вам может потребоваться установить дополнительные пакеты.

Менеджеры пакетов на базе Arch

Arch Linux использует диспетчер пакетов pacman. В отличие от файлов .deb или .rpm, pacman использует более традиционный tarball со сжатием LZMA2 (.tar.xz). Это позволяет пакетам Arch Linux быть намного меньше, чем другие форматы сжатых архивов (например, gzip). Первоначально выпущенный в 2002 году, pacman неуклонно развивался и улучшался. Одним из основных преимуществ pacman является то, что он поддерживает Arch Build System, систему для создания пакетов из исходного кода. Система сборки использует файл PKGBUILD, который содержит метаданные (такие как номера версий, ревизии, зависимости и т. д.), а также сценарий оболочки с необходимыми флагами для компиляции пакета, соответствующего требованиям Arch Linux. Полученные двоичные файлы затем упаковываются в вышеупомянутый файл .tz.xz для pacman.

Эта система привела к созданию Arch User Repository (AUR), который представляет собой репозиторий, основанный сообществом и содержащий файлы PKGBUILD и поддерживающий патчи или скрипты. Это позволяет использовать практически бесконечное количество программ в Arch. Очевидным преимуществом этой системы является то, что если пользователь (или майнтайнер) хочет сделать программное обеспечение доступным для общественности, им не нужно проходить официальные каналы, чтобы разместить его в основных репозиториях. Недостатком является то, что он зависит от сообщества, подобного Docker Hub, пакетам Canonical Snap или другим аналогичным механизмам. Существует множество AUR-специфичных менеджеров пакетов, которые можно использовать для загрузки, компиляции и установки из файлов PKGBUILD в AUR (мы рассмотрим их позже).

Работа с pacman и официальными репозиториями

Главный менеджер пакетов Arch, pacman, использует флаги вместо команд, таких как yum и apt. Например, чтобы найти пакет, вы должны использовать команду pacman -Ss. Как и в большинстве команд Linux, вы можете найти как man-страницу, так и встроенную справку. Большинство команд для pacman используют флаг синхронизации (-S).

Например:

user@arch ~ $ pacman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
    Advanced Text Editor
extra/libkate 0.4.1-6 [installed]
    A karaoke and text codec for embedding in ogg
extra/libtiger 0.3.4-5 [installed]
    A rendering library for Kate streams using Pango and Cairo
extra/ttf-cheapskate 2.0-12
    TTFonts collection from dustimo.com
community/haskell-cheapskate 0.1.1-100
    Experimental markdown processor.

Arch также использует репозитории, подобно другим менеджерам пакетов. В вышеприведенном выводе результаты поиска предваряются репозиторием, в котором они находятся (extra/ и community/ в этом случае). Подобно системам Red Hat и Debian, Arch полагается на пользователя, чтобы добавить информацию о репозитории в конкретный файл. Место хранения для этих репозиториев - /etc/pacman.conf. Пример ниже довольно близок реальной задаче. Я включил репозиторий [multilib] для поддержки Steam:

[options]
Architecture = auto

Color
CheckSpace

SigLevel    = Required DatabaseOptional
LocalFileSigLevel = Optional

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

[community]
Include = /etc/pacman.d/mirrorlist

[multilib]
Include = /etc/pacman.d/mirrorlist

В pacman.conf можно указать определенный URL. Эта функциональность может быть использована для того, чтобы все пакеты получались с определенного момента времени. Если, например, у пакета есть ошибка, которая сильно влияет на ваши задачи, и он имеет несколько зависимостей, вы можете вернуться к определенному моменту времени, добавив в свой файл pacman.conf определенный URL-адрес, а затем выполнив команды для даунгрейда системы:

[core]
Server=https://archive.archlinux.org/repos/2017/12/22/$repo/os/$arch

Подобно системам на базе Debian, Arch не обновляет информацию о локальном репозитории, пока вы не скажете ему об этом. Вы можете обновить базу данных пакета, выполнив следующую команду:

Как видно из вышесказанного, pacman считает, что база данных multilib пакета обновлена. Вы можете обновить ее принудительно, если считаете, что это неверно, запустив команду pacman -Syy. Если вы хотите обновить всю систему (исключая пакеты, установленные из AUR), вы можете запустить команду pacman -Syu:

В сценарии, упомянутом ранее относительно даунгрейда системы, вы можете принудительно выполнить даунгрейд, с помощью команды pacman -Syyuu. Важно отметить, что это не следует воспринимать легкомысленно. В большинстве случаев это не должно вызывать проблемы; однако есть вероятность того, что даунгрейд пакета или нескольких пакетов вызовет каскадный сбой и оставит систему в несогласованном состоянии. ИСПОЛЬЗУЙТЕ С ОСТОРОЖНОСТЬЮ!

Чтобы установить пакет, просто используйте команду pacman -S kate:

Чтобы удалить пакет, вы можете запустить команду pacman -R kate. Она удаляет только пакет, а не его зависимости:

user@arch ~ $ sudo pacman -S kate

checking dependencies...

Packages (1) kate-18.04.2-2

Total Removed Size:  20.30 MiB

:: Do you want to remove these packages? [Y/n]

Если вы хотите удалить зависимости, не требуемые другими пакетами, вы можете выполнить команду pacman -Rs:

Pacman, на мой взгляд, предлагает наиболее краткий способ поиска имени пакета для данной программы. Как показано выше, yum и apt оба полагаются на путь, чтобы найти полезные результаты. Pacman делает некоторые разумные предположения относительно того, какой пакет вы, скорее всего, ищете:

user@arch ~ $ sudo pacman -Fs updatedb
core/mlocate 0.26.git.20170220-1
    usr/bin/updatedb

user@arch ~ $ sudo pacman -Fs kate
extra/kate 18.04.2-2
    usr/bin/kate

Работа с AUR

Есть несколько популярных помощников менеджера пакетов AUR. Из них довольно популярны yaourt и pacaur. Однако в Arch Wiki оба проекта перечислены как остановленные или проблемные. По этой причине я обсужу aurman. Он работает почти так же, как pacman, за исключением того, что он ищет программы в AUR и включает некоторые полезные, хотя и потенциально опасные возможности. Установка пакета из AUR будет инициировать использование скриптов сборки стороннего разработчика. Вам будет предложено несколько раз сделать подтверждения для продолжения установки (я сократил вывод для краткости):

aurman -S telegram-desktop-bin
~~ initializing aurman...
~~ the following packages are neither in known repos nor in the aur
...
~~ calculating solutions...

:: The following 1 package(s) are getting updated:
   aur/telegram-desktop-bin  1.3.0-1  ->  1.3.9-1

?? Do you want to continue? Y/n: Y

~~ looking for new pkgbuilds and fetching them...
Cloning into 'telegram-desktop-bin'...

remote: Counting objects: 301, done.
remote: Compressing objects: 100% (152/152), done.
remote: Total 301 (delta 161), reused 286 (delta 147)
Receiving objects: 100% (301/301), 76.17 KiB | 639.00 KiB/s, done.
Resolving deltas: 100% (161/161), done.
?? Do you want to see the changes of telegram-desktop-bin? N/y: N

[sudo] password for user:

...
==> Leaving fakeroot environment.
==> Finished making: telegram-desktop-bin 1.3.9-1 (Thu 05 Jul 2018 11:22:02 AM EDT)
==> Cleaning up...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) telegram-desktop-bin-1.3.9-1

Total Installed Size:  88.81 MiB
Net Upgrade Size:       5.33 MiB

:: Proceed with installation? [Y/n]

Иногда вам будет предложено ввести больше ввода, в зависимости от сложности устанавливаемого вами пакета. Чтобы избежать этой скуки, aurman позволяет вам передавать параметры --noconfirm и --noedit. Это эквивалентно утверждению «принимать все значения по умолчанию и доверять тому, что скрипты, поддерживающие пакет, не будут вредоносными». ИСПОЛЬЗУЙТЕ ЭТО ВАРИАНТ С ЭКСТРЕМАЛЬНОЙ ОСТОРОЖНОСТЬЮ! Хотя эти варианты вряд ли разрушат вашу систему сами по себе, вы никогда не должны слепо принимать чужие сценарии.

Заключение

Эта статья, конечно, показывает только основные возможности менеджеров пакетов. Есть также множество других менеджеров пакетов, которые я не мог охватить здесь. Некоторые дистрибутивы, такие как Ubuntu или Elementary OS, проделали большую работу, чтобы обеспечить графический интерфейс для управления пакетами.

Приложение

# поиск пакетов
yum search <package>
dnf search <package>
zypper search <package>
apt-cache search <package>
apt search <package>
pacman -Ss <package>
# установка пакетов
yum install <package>
dnf install <package>
zypper install <package>
apt-get install <package>
apt install <package>
pacman -Ss <package>
# обновление базы данных пакетов, не требуется для yum, dnf и zypper
apt-get update
apt update
pacman -Sy
# обновление всех пакетов в системе
yum update
dnf update
zypper update
apt-get upgrade
apt upgrade
pacman -Su
# удаление установленного пакета
yum remove <package>
dnf remove <package>
apt-get remove <package>
apt remove <package>
pacman -R <package>
pacman -Rs <package>
# поиск названия пакета, содержащего заданный файл или папку
yum whatprovides *<binary>
dnf whatprovides *<binary>
zypper what-provides <binary>
zypper search --provides <binary>
apt-file search <binary>
pacman -Sf <binary>

Если вам понравилась статья, поделитесь ею с друзьями: