Графические менеджеры пакетов linux

Управление программными пакетами

Пакетный менеджер Nix — это инструмент, предлагающий простой подход для управления бинарными пакетами и пакетами на основе исходных кодов независимо от версии вашего дистрибутива, будь то Ubuntu, D

P-Launcher

Графический интерфейс для системы управления пакетами apt в Debian, Ubuntu и их модификаций, а так же apt-rpm в PCLinuxOS и некоторых других.

Pacgraph

Pacgraph малоизвестная среди большинства пользователей Linux маленькая консольная утилита для визуализации установленных в системе пакетов и зависимостей между ними. Разработчик Kyle Keen.

pacinfo

pacinfo — маленькое Mono / GTK графическое приложение для просмотра информации об установленных пакетах. Приложение предназначено для использования в ArchLinux, информация о пакетах берётся из pacman.

Package Converter

Package Converter это удобная QT графическая оболочка (GUI) дающая простой способ использования некоторых базовых возможностей консольной утилиты Alien.

PackageKit

PackageKit — комплект инструментов, надстройка над различными системами управления пакетами, предназначенная для упрощения процесса установки, удаления и обновления программного обеспечения.

Pacman

Pacman — официальный менеджер пакетов в дистрибутиве Arch Linux. Является мощной системой управления пакетами и в то же время простой в изучении.

Paludis

Paludis — альтернативный менеждер пакетов для достаточно популярного дистрибутива Gentoo, развивается с января 2006 года, приносит множество нововведений и улучшений, уже используется в качестве основного на экспериментальном дистрибутиве Exherbo.

pkg++ — это инструмент для создания пакетов ПО. Цель проекта — предоставить инструмент, с помощью которого вы можете собрать пакет для вашего дистрибутива/ОС на основе исходного предписания (recipe) и для используемого в вашей системе пакетного менеджера.

RPM (рекурсивный акроним RPM Package Manager — RPM — менеджер пакетов; ранее раскрывался как Red Hat Package Manager — менеджер пакетов Red Hat) обозначает две вещи: формат пакето

Источник

Менеджер пакетов Synaptic

Содержание

Synaptic — это графическая программа, позволяющая управлять пакетами в Ubuntu. Она совмещает в себе все возможности консольной системы управления пакетами apt и удобство графического интерфейса. С помощью Synaptic вы можете устанавливать, удалять, настраивать и обновлять пакеты в вашей системе, просматривать списки доступных и установленных пакетов, управлять репозиториями и обновлять систему до новой версии.

Установка

Начиная с Ubuntu 11.10 Synaptic не распостраняется в комплекте стандартных программ. Установить его можно нажав на ссылку слева или введя в терминале команду:

Запуск и внешний вид

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

Для запуска Synaptic откройте Главное меню 1) и наберите в поиске synaptic . Также Synaptic можно запустить введя в терминале команду:

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

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

Если вы выберите «Все», вы увидите полный список доступных и установленных пакетов. При нажатии «Установленные» будут показываться лишь установленные пакеты и так далее. Правая часть окна разделена на верхнюю и нижнюю части. В верхней части выводится список пакетов, и при выбора пакета из этого списка в нижней части отображаются сведения о нем и его описание.

Пакеты могут быть сгруппированы по функциональности (текстовые редакторы, документация, почтовые клиенты и т.д.). Для этого используется кнопка «Разделы». После нажатия на нее вы сможете выбирать пакеты из различных секций.

Управление ПО

Установка

Удаление

Обновление

Обновление всей системы

Synaptic предоставляет два варианта обновления системы

Умное обновления (рекомендуется)

Умное обновление попытается разрешить конфликты пакетов перед обновлением системы. Действие умного обновления аналогично действию команды apt-get dist-upgrade .

Стандартное обновление обновит только те пакеты, которые не требуют установки дополнительных зависимостей.

По умолчанию ynaptic использует умное обновление. Для того чтобы изменить метод обновления системы откройте Настройки→Параметры→Основные и выберите требуемый способ в Обновление системы.

Как исправить сломанные пакеты

«Сломанные пакеты» — это пакеты которые имеют неудовлетворённые зависимости. Если сломанные пакеты обнаружены, то Synaptic не позволит проводить ни каких изменений в системе с пакетами до тех пор пока все сломанные пакеты не будут исправлены.

Для исправления сломанных пакетов

Горячие клавиши в Synaptic

Команда	Сочетание клавиш
Обновить список доступных пакетов	Ctrl + R
Открыть диалоговое окно поиска	Ctrl + F
Показать окно с свойствами выбранного пакета	Ctrl + O
Отметить выбранный(е) пакет(ы) для установки	Ctrl + I
Отметить выбранный(е) пакет(ы) для обновления	Ctrl + U
Отметить выбранный(е) пакет(ы) для удаления	Delete
Отметить выбранный(е) пакет(ы) для полного удаления	Shift + Delete
Снять какие-либо изменения в пакетах	Ctrl + N
Отметить все возможные обновления	Ctrl + G
Быстрая установка специфической версии для пакета	Ctrl + E
Отменить последнее изменение	Ctrl + Z
Повторить последнее изменение	Ctrl + Shift + Z
Применить все выбранные действия	Ctrl + P
Выйти из Synaptic	Ctrl + Q

Настройка кэширования пакетов

Настройки кэширования пакетов находятся в двух местах. Первое – в самом synaptic, окно с настройками кэширования вызывается через меню Настройки→Параметры→Файлы.

Кэш хранится в папке /var/cache/apt/archives/

В разделе Файлы истории устанавливаются настройки времени хранения истории установок, либо отключается удаление этой истории вообще.

Второе место в котором хранятся настройки кэширования устанавливает правила хранения пакетов в кэше. Для того чтобы получить доступ к этим настройкам необходимо в терминале выполнить следующую команду:

Эти настройки имеют следующий вид:

Здесь отображаются максимальный, минимальный срок хранения пакета в днях и максимальный размер кеша в мегабайтах. В данном случае все пакеты старше 30 дней будут удалены, даже если размер кэша менее 500 мб, и ни один пакет младше 2 дней удален не будет, даже если размер кэша превысит 500 мб.

Источник

Эволюция менеджеров пакетов в 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

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

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

Менеджеры пакетов на основе 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:

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

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

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

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

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

Бывают случаи, когда вы не знаете имя пакета, но знаете имя утилиты. Например, предположим, что вы ищете утилиту updateb, которая создает/обновляет базу данных, используемую командой locate. Попытка установить 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 в систему добавляются репозитории. В отличие от описанных выше менеджеров пакетов, zypper добавляет репозитории, используя сам менеджер пакетов. Наиболее распространенным способом является URL-адрес, но zypper также поддерживает импорт из файлов репо.

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

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

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

Как и в случае с 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 и др.). Чтобы обеспечить одинаковую работу системы во всех дистрибутивах, я расскажу только о вариантах командной строки. Чтобы добавить репозиторий без прямого редактирования файла, вы можете сделать что-то вроде этого:

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

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

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

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

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

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

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

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

Большинство из этих примеров использовали 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).

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

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

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

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

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

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

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

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

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

Работа с AUR

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

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

Заключение

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

Источник