Зависимости
Мефодий нашёл в Интернете пакет с заинтересовавшей его программой в подходящем формате rpm и решил попробовать его установить.
Для установки и удаления пакетов нужны права администратора — это серьёзные изменения в системе.
Пример 8. Пакет не установлен из-за неудовлетворённых зависимостей
Однако rpm отказался выполнять установку, ссылаясь на зависимость от другого пакета. Здесь Мефодий впервые столкнулся с тем, что пакеты — не всегда (точнее, почти никогда) бывают независимы от имеющейся системы. В разделе Package..Архив файлов уже говорилось о том, что для работы программы нужны различные ресурсы, причём несколько программ могут нуждаться в одном и том же ресурсе. В последнем случае общий ресурс может оказаться в отдельном собственном пакете (чтобы не включать его сразу в несколько), и этот пакет должен быть установлен в системе, чтобы заработали нуждающиеся в нём программы. Потребность пакета в ресурсах, находящихся в другом пакете, называют зависимостью этого пакета от другого. В процедуре установки rpm проверяет, все ли зависимости устанавливаемого пакета удовлетворены (т. е. все ли необходимые пакеты уже установлены в системе), и если чего-то не хватает — прекращает установку. Именно с такой ситуацией и столкнулся Мефодий.
зависимость пакетов Ситуация, при которой пакет не может быть установлен в систему, если в ней не установлен хотя бы один из некоторого множества пакетов. Аналогично, пакет не может быть удалён из системы до тех пор, пока в ней установлен хотя бы один зависящий от него пакет.
Библиотеки
Мефодию помешала установить пакет самая типичная зависимость — на библиотеку. Библиотеки возникают оттого, что все программы, сколько бы они не отличались друг от друга, нуждаются в выполнении одних и тех же операций: вводе и выводе, получении доступа к ресурсам системы (памяти, процессорному времени, файлам), вычислениях, работе с сетью, рисовании окошек, кнопок, меню и т. п. Для выполнения таких операций используются небольшие подпрограммы — функции. Любые функции, необходимые более чем одной программе, есть смысл не включать в текст каждой программы, а собирать в отдельных библиотеках. Тогда программа сможет использовать не собственную подпрограмму, а готовую функцию из библиотеки. Поскольку библиотеки нужны нескольким программам, они обычно оформляются в виде отдельного пакета. Если библиотека не будет установлена, использующая её программа просто не будет работать.
Библиотеки подвержены тем же изменениям с течением времени, что и все прочие программы: исправлению обнаруженных ошибок, модернизации, оптимизации и пр. Поэтому версии библиотек должны быть согласованы с версией программного обеспечения. Например, программа может отказаться работать даже при наличии библиотеки, если эта библиотека слишком старая либо слишком новая по сравнению с самой программой.
Цепочки зависимостей
Однако понятие зависимости включает не только зависимость программы от библиотек. Вообще говоря, зависимость возникает там, где программное обеспечение использует любой не поставляемый непосредственно с ним ресурс.
Имеет смысл исключать из понятия зависимости использование наиболее стандартных ресурсов, без которых немыслима система Linux как таковая. К таким ресурсам можно отнести системные вызовы и некоторые стандартные файлы, вроде /dev/null .
Это могут быть и утилиты, которые запускаются при работе самой программы или во включённых в пакет сценариях, программа-интерпретатор для исполнения этих сценариев, и даже определённые файлы, которые должны присутствовать для правильной работы программы (например, утилита passwd предполагает, что существует файл /etc/passwd ).
Зависимость может быть и небезусловной. Например, в некоторых случаях нужно обеспечить наличие ресурса не к моменту запуска программы, а прямо к моменту установки пакета, так, для выполнения доустановочного сценария нужна программа-интерпретатор. В некоторых случаях требуется ресурс строго определённой версии, ни больше, ни меньше. Бывают случаи, когда зависимость имеет обобщённую форму, например, почтовому клиенту (программе для чтения и написания электронной почты) может требоваться служба доставки электронной почты. В Linux такую услугу предоставляют несколько разных программ, и любая из них удовлетворит зависимость.
Разобравшись с понятием зависимости, Мефодий набрался твёрдой решимости установить-таки нужный ему пакет, установив всё, что он потребует. Но не тут-то было: взявшись устанавливать библиотеки, Мефодий выяснил, что каждой из них требуются какие-то ещё пакеты, отсутствующие в системе, у каждого из них тоже есть зависимости и т. п. — один единственный пакет повлёк за собой снежный ком других, вытягивая их по цепочкам зависимостей.
Конфликты и альтернативы
В противоположность зависимости, когда пакет не может быть установлен при отсутствии некоторого другого, конфликт пакетов — это ситуация, когда пакет не может быть установлен при наличии некоторого другого, т. е. они несовместимы в рамках одной системы. Одна из причин возникновения конфликтов уже упоминалась выше — в пакетах есть файлы с совпадающими именами. Самый распростанённый источник конфликтов — программы, которые предоставляют разные реализации одной и той же функциональности системы (например, службы доставки электронной почты или печати, программы проверки орфографии, компиляторы и т. п.). Можно было бы, конечно, просто назвать конфликтующие файлы по-разному, но и тогда путаница неизбежна: если, допустим, старый компилятор Си называется gcc2.96 , а новый — gcc3.3 , то что запускается по стандартной команде gcc ? В каждом пакете должна содержаться информация о том, с какими пакетами он конфликтует. Конфликт пакетов может быть разрешён очень просто: следует удалить один из конфликтных пакетов, после чего свободно устанавливать другой.
Каждый пакет помимо имени обозначен и номером версии, указывающим степень обновлённости содержащегося в пакете программного обеспечения и самого пакета. В системе одновременно может быть установлена только одна версия любого пакета, со всеми остальными версиями она конфликтует. Такой подход вполне понятен, поскольку файлы в пакете имеют строго определённый путь, по которому они должны быть размещены в файловой системе. Поэтому при использовании пакетов не должно (и не может) возникнуть ситуации, когда одна и та же программа установлена в разных местах файловой системы.
Однако не все функции в системе должны эксклюзивно выполняться одной программой. Например, в системе может быть установлено сколько угодно текстовых редакторов, и даже несколько разных реализаций одного редактора, например, Vim (Vi и nvi). Пакеты Vi и nvi не конфликтуют друг с другом, однако оба могут с равным правом быть вызваны по команде vi . Чтобы определить, какой именно из них запускать как vi , во многих дистрибутивах Linux (в частности, в том, который использует Мефодий) используется механизм альтернатив. Альтернативы — это система символьных ссылок на принадлежащие пакетам файлы. Однотипные файлы из пакетов называются по-разному, а символьная ссылка, к которой обращается пользватель, указывает на один из них. Например, файл /usr/bin/vi может быть символьной ссылкой либо на /usr/bin/vim , либо на /usr/bin/nvi (то же самое относится и к руководствам по этим редакторам). При установке и удалении любого из пакетов с одной из альтернативных программ символьная ссылка автоматически обновляется. На какую из них будет указывать ссылка решается на основании веса каждого пакета. Вес — это условное число, выбирается та альтернатива из установленных, у которой наибольший вес. Пользователь может вмешаться в выбор альтернатив и вручную. Все необходимые утилиты для работы с альтернативами предоставляет пакет alternatives .
Репозитории, пакеты, менеджеры пакетов и зависимости в Linux
Приветствую, дорогие друзья, знакомые и прочие личности.
Как Вы наверняка знаете и помните, я обещал потихоньку (по вашим просьбам) охватывать цикл Linux , знакомя Вас с разными основами и очень постепенно перетекая из теории в практику.
Сегодня мы пока что продолжим тему знакомства с теорией и основами, а посему поговорим о такой штуке, как репозитории и обо всём, что с ними связано, т.е. разберемся как же выглядит изнутри софт в Linux , как это все хранится и всё такое прочее.
Как и в случае со статьей «Графические оболочки в Linux [основы основ, работа в KDE]», всё, в общем-то, просто, но необходимо по ходу чтения несколько напрячь мозг, дабы не запутаться в хитросплетении терминов и несколько скомканном повествовании. В общем, следите за мыслью 🙂 При необходимости прочитайте статью дважды 😉
Поехали. Все программы в дистрибутивах Linux это отдельные проекты, которые развиваются сами по себе. Вы должны представить себе некую цепочку: есть отдельные пакеты (программное обеспечение), есть зависимости (ниже мы более подробно рассмотрим эти понятия). Цель же всего этого – собрать все эти программы, с их зависящими друг от друга библиотеками вместе, да не просто собрать, а сделать так, чтобы все это работало в комплексе.
У каждого дистрибутива есть свои разработчики (майнтейнеры). Эти люди занимаются тестированием различных пакетов на их нормальное функционирование, взаимную совместимость, а также часто добавляют собственные усовершенствования или не успевшие войти в официальную сборку и, в конечном итоге, отвечающие за включение пакета в дистрибутив патчи. Т.е. разработчики берут программы из открытых исходных кодов и начинают подгонять их друг к другу, упаковывая в пакеты и соблюдая все зависимости, тестируя и удаляя ошибки из этих самых программ. Представили? Тогда, думаю, Вы понимаете, что это непростое занятие. Так вот, все эти подогнанные друг к другу программы, библиотеки и нескучные обои, упакованные в пакеты со всеми зависимостями, – это и есть репозиторий Вашего дистрибутива, откуда программы и устанавливаются на Ваш компьютер.
О репозиториях в Linux. Что это и зачем нужно
Т.е. еще раз и чуть иначе: репозиторий в Линуксе – это все файлы пакетов, принадлежащие одному дистрибутиву (например, Fedora ), одной его версии (например, 16 ), то бишь сие есть огромное хранилище пакетов, которое находится в сети Интернет и которым Вы можете спокойно воспользоваться (причем бесплатно). Те самые ISO -файлы образов для записывания на болванку и последующей установки содержат как раз репозитории пакетов со всеми зависимостями и менеджером пакетов плюс установочную программу, которая разметит жёсткий диск, всё поставит и приготовит Вам рабочий стол (или сервер, или что попросите).
Для чего создаются репозитории? Ответ прост – для централизованного управления обновлением пакетов. Представим на секунду, что у нас нет репозиториев, и Вы установили Linux с диска с определенными (стандартными) программами. Однако время не стоит на месте, все программы обновляются и всё такое прочее. Как же тогда узнать – есть ли обновление для Вашей программы или нет? Естественно, придется посещать сайт разработчиков программы, чтобы выяснить это, что, согласитесь, не совсем удобно, особенно, если программ у Вас установлено очень много. Ну и понеслось, Вы раз проверили, два проверили наличие обновлений, в третий раз забыли, а потом и вообще надоело каждый раз смотреть, вышло там обновление или нет. И тут раз..
Вспоминаем, для чего у нас существуют обновления? А для того, чтобы не просто иметь новый (и улучшенный старый) функционал в оных программах, но еще и залатывать дыры, которые нередко приводят к различным неприятностям, начиная от глюков программы/системы и заканчивая проблемами с безопасностью (я, например, очень не люблю «терять» пароль, скажем, от почты по вине дыр в софте). Поэтому-то разработчики Linux и создали репозитории, с помощью которых можно быстро и удобно отслеживать обновления тех или иных пакетов (да и вообще обновления всей системы в целом), устанавливать новые и обновленные и всё такое прочее. Кстати, почему для Windows оным еще не озадачились, решительно непонятно (хотя там частично спасают программы для обновления программ, пусть это и не совсем то).
О пакетах и менеджерах пакетов в Linux. Что это и зачем нужно
К слову, немного выше я специально выделил три пункта, чтобы, так сказать, разбить содержание на несколько частей. О рeпозитории пакетов мы поговорили и теперь переходим к следующему куску повествования, а именно, поговорим о том, что подразумевается под понятием пакеты в Linux .
Под пакетами в Linux подразумевается программное обеспечение (ПО), которое Вы хотите установить на компьютер. Скажем, например, в Windows софт устанавливается с помощью мастера (программы) установки – setup.exe или install.exe . Вы запускаете этот мифический экзешный файл, и процесс установки начинается едва ли не мгновенно после выбора пути и мелких побочных настроек.
Установка же программ в Linux несколько отличается тем, что здесь используются два основных способа инсталляции: с помощью пакетов или из исходных кодов (установка пакетов это отдельный разговор, и сейчас мы этого вопроса касаться не будем). Пакет содержит собранную программу, информацию о том, какие требуется совершить действия для ее установки, информацию о зависимостях, а также, возможно, много других данных (в зависимости от вида пакета) . Причем за установку (удаление, обновление) отвечает такая штука, как менеджер пакетов .
Обычно менеджер пакетов является сердцем дистрибутива, обеспечивая полный контроль целостности и работоспособности всей системы, и он же обеспечивает пользователю интерфейс для автоматизированного получения пакета, его зависимостей и его установку. Пакеты, как уже говорилось, собираются в репозитории, т.е. всё это можно сложить в одну цепочку: пользователь запрашивает установку пакета – менеджер пакетов отслеживает зависимости – он же получает необходимые пакеты из репозитория(ев) – и он же устанавливает зависимости и требуемый пакет. Практически каждый дистрибутив Linux имеет свои репозитории, зачастую несовместимые с другими дистрибутивами. Менеджер же пакетов – консольная утилита, однако обычно для нее существуют многочисленные графические оболочки, которые легко отыскать в каждом дистрибутиве, введя в поиск « Установка/удаление программ ».
Пакетные менеджеры бывают разные. Для управления пакетами в разных дистрибутивах используются разные программы. В общем-то, их не так уж и мало, а посему выделим «основные», которые «умеют» разрешать зависимости. Фраза «умеют разрешать зависимости» означает следующее – если при установке пакета будет обнаружено, что для корректной его установки нужны дополнительные пакеты, то менеджер пакетов установит их сам, т.е. Вам не придется искать дополнительные пакеты в репозиториях. Те менеджеры пакетов, которые не обладают такой функцией (умением разрешать зависимости), мы рассматривать не будем, ибо оные только сообщат Вам, что пакет установить невозможно и выведут весь список файлов (именно файлов, а не пакетов), которые нужны для установки данного пакета. А уж какой файл в каком пакете находится, Вы будете догадываться и искать самостоятельно.
Вот небольшой список:
- Yum (Yellow Dog Update Modified) – мощный менеджер пакетов, основанный на rpm (простой МП, не умеет разрешать зависимости), работающий в текстовом режиме и умеющий разрешать зависимости, а также умеющий поддерживать репозитории (источники пакетов). Используется в RedHat Linux , а так же в Fedora , SuSe и некоторых других;
- APT [Advanced Package Tool] создана для дистрибутивов Linux , основанных на Debian , используется в Ubuntu (и клонах), АLT Linux и др. Мощный менеджер пакетов, работающий в текстовом режиме. Умеет разрешать зависимости и поддерживает репозитории (источники пакетов);
- Portage package management system имеет много разновидностей, примером может служить дистрибутив Gentoo . Как вариант пакетного менеджера можно привести emerge .
К слову, пакетные менеджеры не просто ищут желаемые Вами программы по описаниям, но прежде нам нужно ввести еще один не раз уже упомянутый термин и объяснить его.
О зависимостях в Linux. Что это и зачем нужно
Например, Вы захотели установить программу и нажали кнопку « Установить », а она спрашивает Вас про какие-то мифические и непонятные зависимости . Так давайте разберемся – а что же это такое?
Часто компоненты, используемые различными программами, выделяют в отдельные пакеты и помечают, что для работы ПО , предоставленного пакетом A , необходимо установить пакет Б . В таком случае говорят, что пакет A зависит от пакета Б или что между пакетами A и Б существует зависимость (обычно в роли зависимостей выступают какие-либо библиотеки, без которых программа не будет запускаться, поскольку использует функции этой библиотеки). Вот как раз отслеживанием зависимостей между такими пакетами и занимается уже неоднократно упомянутый менеджер пакетов. Говоря просто, пакетный менеджер это такая программа, которая ведёт базу данных установленных приложений и их версий, и всегда знает, какие файлы куда установлены, чтобы можно было поставить новые программы, удалить старые или обновить всю систему целиком без переустановки и вычищения мусора оставшихся файлов.
Вся эта огромная куча пакетов с их ворохом зависимостей друг от друга, управляемая пакетным менеджером, как раз и составляет Ваш дистрибутив Linux . Но это не просто куча мусора, а упорядоченная система, которая называется — та-дам! — репозитории пакетов программ . Круг замкнулся – мы вернулись к первому понятию – что такое репозиторий 🙂
Несколько слов о нюансах
Напоследок все-таки хочется сказать, что какой бы Linux не была устойчивой, стабильной и неубиваемой, всё же пользователь должен придерживаться определенной осторожности. Например:
- Не надо искушать судьбу и ставить программы в Linux в обход менеджера пакетов, простой компиляцией. Работать они будут, но пакетный менеджер ничего о них не будет знать, из-за чего при обновлении системы или программ Вы рискуете получить больше проблем на свою голову, чем представляете. Устанавливайте программы только в виде пакетов.
- Не надо подключать те репозитории, о которых имеете совсем смутное представление. Например, не надо подключать репозитории со словами testing , debug и тому подобными терминами, ибо эти репозитории в первую очередь предназначены для самих разработчиков дистрибутивов и далеко не всегда стабильны.
- Не подключайте подряд все доступные репозитории, это тоже может сыграть с Вами злую шутку. Подключайте только самые необходимые, не надо жадничать 🙂
Например, при установке операционной системы Fedora по умолчанию сразу подключены два репозитория:
- Fedora (пакеты, которые подходят на любую комбинацию из компакт-дисков или DVD-дисков)
- Updates (обновленные пакеты, новее, чем репозиторий (хранилище) Fedora)
Для нормальной работы нужно подключить дополнительный репозиторий rpmfusion (без него Вам действительно не обойтись), что даст доступ к программам, которые не могли быть включены в дистрибутив из-за лицензионных ограничений (приложения, которые требуются для воспроизведения мультимедиафайлов, таких как mp3 , dvd и т.д.; драйвера – к ним относятся проприетарные драйвера для ATI и NVIDIA ; игры: Bub’s Brothers, Secret Maryo Chronicles, UFO: Alien Invasion, Wörms of Prey, xrick, GLtron и многие, многие другие; эмуляторы: эмулятор Commodore 64 , а также Commodore 8 bit , эмулятор Amiga, Nestopia, ZSNES и много других). Чтобы подключить этот репозиторий, достаточно в командной строке (терминале) от суперпользователя (root) ввести команды:
$ sudo rpm -ivh https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm
$ sudo rpm -ivh https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm
Обратите внимание, что репозиторий rpmfusion разделяется на две части: free и nonfree . Первый содержит чисто свободные программы в понимании FSF , распространяемые под GPL и совместимыми с ней лицензиями. Содержимое второго, вопреки названию, — также программы по преимуществу свободные, но попадающие под пресловутые патентные ограничения некоторых государств (например, аудио- и видеокодеки).
То же самое касается и менеджера пакетов в Fedora . Для нормальной и удобной работы менеджера пакетов (yum) в Fedora рекомендуется подключить дополнительный плагин fastestmirror . Этот плагин очень важен: он определяет не просто ближайшее зеркало, как это делают аналогичные утилиты из других систем управления пакетами, а устанавливает именно самое быстрое зеркало в данный момент – по времени отклика.
$ sudo yum install yum-plugin-fastestmirror
В двух словах как-то так 🙂
Послесловие
Я понимаю, что без практики воспринять всё это с налёта довольно сложно, но делать нечего — это самые начальные и базовые теоретические сведения, с которыми каждый пользователь должен быть знаком хотя бы как-то, дабы иметь представление, что к чему и почему, а не слепо тыкаться в кнопки и читать незнакомые термины.
В следующих статьях мы рассмотрим, что именно из себя представляет установка пакетов в Linux , как в этой операционке устроена файловая система, что подразумевается под пользователем (и кто такой суперпользователь, он же root), а так же поговорим о программах и кой о чем другом. Оставайтесь с нами.
Как и всегда, если есть какие-то вопросы, дополнения и всё такое прочее, то буду рад видеть их в комментариях к этому материалу.
P.S. За существование данной статьи спасибо члену команды Pantera
Белов Андрей (Sonikelf) alt=»Sonikelf» /> alt=»Sonikelf» />Заметки Сис.Админа [Sonikelf’s Project’s] Космодамианская наб., 32-34 Россия, Москва (916) 174-8226
Менеджеры пакетов в системах linux
В двух словах, управление пакетами это установка и поддержка (обновление или удаление при необходимости), программного обеспечения операционной системы. На ранних стадиях развития операционных систем Linux, программное обеспечение для них распространялось только в виде исходного кода, вместе с необходимой документацией, файлами конфигурации и т. д. В настоящее время большинство дистрибутивов Linux используют уже скомпилированные программы, называемые пакетами. Пакеты предоставляются пользователю уже готовыми к установке на операционную систему. Тем не менее в linux, всегда можно получить исходный код того или иного программного обеспечения для изучения, улучшения и компиляции.
Как вывести список зависимостей пакета в Ubuntu
В отличие от Windows, macOS и Android, программное обеспечение в Ubuntu и Linux в целом не распространяется как единый пакет. Вместо этого, когда вы устанавливаете приложение, менеджер пакетов вашей системы загружает несколько пакетов, включая основной пакет приложения и его зависимости. Однако это справедливо только для традиционной установки пакетов в Linux, то есть с использованием менеджеров пакетов.
Информация о том, какие дополнительные зависимости загружаются во время установки, может быть полезно как для начинающих, так и для опытных пользователей. Таким образом, вы получаете полный контроль над пакетами, установленными в его системе.
Давайте посмотрим, как вы можете проверить зависимости пакета в Ubuntu.
Что такое зависимости пакетов?
Зависимости – это пакеты поддержки, необходимые для правильной работы приложения в Linux. Например, если вы хотите загрузить медиаплеер VLC в Ubuntu, APT установит некоторые дополнительные пакеты, такие как libc6 и gcc , в дополнение к основному пакету « vlc ». Зависимость также может иметь другие пакеты в качестве своих зависимостей, таким образом, образуя иерархическую структуру.
Поскольку пакеты Linux взаимозависимы, почти каждое программное обеспечение требует дополнительных пакетов, которые вы должны установить в своей системе.
Хотя менеджеры пакетов, такие как APT, автоматизируют управление и установку указанных зависимостей, при попытке собрать пакет вручную из источника возникают ошибки. Однако вы можете решить такие ошибки, просто установив необходимую зависимость в вашей системе с помощью команды apt install .
Как проверить зависимости пакетов в Linux
К счастью, в Ubuntu есть несколько способов получить список зависимостей пакета. APT, менеджер пакетов по умолчанию в дистрибутивах на основе Ubuntu и Debian, предлагает несколько команд для получения информации о пакете, связанной с зависимостями.
Использование диспетчера пакетов APT
Вы можете использовать APT в Ubuntu, чтобы получить список зависимостей, связанных с пакетом. Основной синтаксис команды:
Например, чтобы проверить зависимости для пакета ритмбокс :
Помимо списка зависимостей, вывод также будет включать рекомендуемые и предлагаемые пакеты, которые вы можете установить вместе сhythmbox .
В качестве альтернативы вы также можете использовать команду apt-cache, чтобы получить тот же результат.
Чтобы получить дополнительную информацию, относящуюся к конкретному пакету, используйте метод show вместо метода depends .
Листинг зависимостей с помощью dpkg
Если вы загрузили пакет DEB в свою систему и хотите знать, какие зависимости будут установлены вместе с пакетом, вы можете использовать флаг -I (с заглавной буквы i, а не с L в нижнем регистре) или –info с командой.
… где /path/to/package.deb – абсолютный или относительный путь к файлу DEB.
В выходных данных будет отображаться размер пакета, источник и другая полезная информация вместе со списком зависимостей.
Чтобы получить список зависимостей для установленного пакета, используйте флаг -s с dpkg. Например:
Использование apt-rdepends
Чтобы получить более подробный вывод, вы можете использовать утилиту apt-rdepends. Поскольку он не предустановлен в большинстве дистрибутивов Linux, вам придется установить его вручную в Ubuntu с помощью APT.
Используйте следующий формат команды, чтобы получить дерево зависимостей для пакета:
Сгенерированный вывод обычно имеет длину, если apt-rdepends отображает полное иерархическое дерево зависимостей, что означает, что вы также получаете список зависимостей зависимости.
Вы также можете получить список пакетов, которые зависят от конкретного пакета. Например, чтобы проверить, для каких пакетов требуется libc в качестве зависимости:
Утилита, зависящая от обратной зависимости
Хотя функция обратной зависимости (флаг -r ) apt-rdepends работает лучше, чем ожидалось, есть еще одна утилита, которую вы можете использовать для извлечения обратных зависимостей пакета. Команда обратной зависимости является частью пакета ubuntu-dev-tools и может быть загружена с помощью:
Синтаксис команды по умолчанию:
… где параметры – это флаги, которые вы можете использовать с командой, а packagename – это имя пакета, для которого вы хотите выполнить обратную проверку зависимостей.
Вы также можете добавить различные флаги к вышеупомянутой команде, чтобы изменить вывод. Вот список наиболее полезных опций:
- -R : перечислить только прямые зависимости (без рекомендуемых или рекомендуемых пакетов)
- -s : включить предложенные пакеты
- -l : представить вывод в более чистом формате, подходящем для использования в скриптах.
Если вы не можете понять, как использовать инструмент и вам нужна справка из командной строки , используйте флаг –help или -h .
Получить список зависимостей с помощью имитации установки / удаления
Для тех, кому нужен краткий список всех зависимостей, которые в настоящее время не установлены в системе, вы можете запустить имитацию установки (или удаления) определенного пакета.
Например, чтобы проверить зависимости, необходимые для пакета PHP, выполните следующую команду:
Вывод будет содержать раздел «Будут установлены следующие дополнительные пакеты». Все перечисленные ниже имена пакетов являются зависимостями, которые не были обнаружены в вашей системе.
Если вы хотите получить список зависимостей для пакета, уже установленного в Ubuntu, вы можете выполнить имитацию удаления, чтобы проверить, какие дополнительные пакеты будут удалены вместе с ним.
Пакеты Linux взаимозависимы
Как вы можете сделать из этого руководства, почти каждый пакет Linux зависит от другого пакета. Основной принцип, лежащий в основе этой концепции, заключается в том, что в операционных системах на базе Linux каждый пакет должен выполнять одну работу и делать ее хорошо.
Если пакет был разработан для управления аудиосервисами, то другие программы будут просто перечислять упомянутый пакет как свою зависимость и использовать его для выполнения своих требований к звуку.
Кроме того, если несколько приложений требуют один и тот же пакет, он устанавливается в системе только один раз, что предотвращает избыточность данных и экономит место на диске. Вы также можете получить список всех пакетов, установленных в настоящее время в вашей системе, с помощью APT.