Менеджеры пакетов в Linux » Crossroads
 

 
Crossroads » BLOG » Записки чайника » Менеджеры пакетов в Linux

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

  • Dislike
  • 0
  • Like
Менеджеры пакетов в LinuxУстановка ПО (или пакетов) в дистрибутивах Linux происходит «централизованно», что удобно, но часто вызывает вопросы у новичков. И так, максимально доходчиво я постараюсь объяснить, почему всё не так как в Windows и зачем знать базовые команды консольного менеджера пакетов, если в любом современном дистрибутиве есть графический интерфейс.

Если вы интересуетесь темой Linux, то знаете о существовании множества дистрибутивов и о том, что нередко они несовместимы между собой. Точнее, готовые пакеты одного дистрибутива несовместимы с другими дистрибутивами, особенно если это не производные друг от друг дистрибутивы. Поэтому у каждого дистрибутива есть свои репозитории готовых пакетов, собранных исключительно под конкретный дистрибутив. Из этих репозиториев пакетный менеджер и берёт пакеты. Но это не единственная и далеко не основная причина того, что пакеты для Linux систем распространяются таким образом.

При установке той или иной программы через пакетный менеджер видно, что вместе с пакетом самой программы, в систему устанавливается ещё куча всяких пакетов. Чем сложнее программа и чем «чище» ваша система, тем больше пакетов устанавливается в качестве «зависимостей». Зависимости – это системные библиотеки, а иногда и другие программы, необходимые для работы устанавливаемой программы. Каждый пакет в репозитории содержит файл-манифест, в котором указаны все зависимости. В Windows также, некоторые упакованные программы требуют наличия определённых компонентов в системе. Например, для игр необходимо наличие библиотек DirectX в каталоге «system32» и так далее. Это те же зависимости. Установщик программы видит их наличие и сообщит вам о их отсутствии, если не найдёт соответствующую запись в реестре. На самом деле, в Windows программы часто просто не запускаются или вылетают с ошибкой, но причина именно в отсутствии того или иного компонента. В Linux же пакет просто не будет установлен, если нет возможности соблюсти все зависимости. Разбором зависимостей и занимается пакетный менеджер. В идеале в репозиториях дистрибутива есть всё необходимое для соблюдения всех зависимостей всех пакетов. В этом заключается опасность использования сторонних репозиториев. Если информация о зависимостях в них устарела, или содержит ошибки, то использование пакетов из таких репозиториев может вызвать проблемы той или иной сложности. Имена пакетов, системных библиотек и их версии в разных дистрибутивах отличаются. Поэтому невозможно без плясок с бубном взять пакет из Ubuntu и установить его в OpenSUSE. Теоретически это можно сделать, пересобрав пакет и установив нужные зависимости, но такой пакет не будет обновляться, даже если не вызовет других проблем. Всегда нужно устанавливать пакеты именно для вашего дистрибутива и к другим способам прибегать только в случае крайней необходимости. Если ваш дистрибутив не содержит всего того, что вам нужно, то это серьёзный повод для смены дистрибутива.

Существует несколько пакетных менеджеров со своими плюсами и минусами, а также сам подход к зависимостям у большинства дистрибутив отличается. Кроме пакетов с ПО, существуют так называемые «мета-пакеты», которые содержат только инструкции по зависимостям. Мета-пакеты используются для установки комплексных решений в один клик. Например, мета-пакеты рабочих столов, когда установкой одного мета-пакета можно установить окружение рабочего стола и кучу прикладного ПО. Та же ситуация и с удалением. Рано или поздно вы захотите удалить неиспользуемое ПО, входящее в состав дистрибутива. И, в зависимости от дистрибутива, можете обнаружить, что удаление почтовой программы удаляет также мета-пакет рабочего стола, что помечает половину пакетов в вашей системе как «ненужные». Пакеты, установленные как зависимости, могут быть безболезненно удалены как в процессе удаления основного пакета, так и после. Беда в том, что мета-пакет рабочего стола был указан как жёсткая зависимость почтовой программы. Имеется в виду, что без рабочего стола она работать не будет. Но не учитывается, что рабочий стол без почтовой программы может работать без каких-либо проблем. В итоге, после невнимательного удаления чего-либо действительно ненужного, можно обнаружить, что система стала легче гигабайт на 5, но при этом загружается в чёрный экран и командную строку. Такой подход к зависимостям свойственен, например, Ubuntu, тогда как пакетный менеджер в Arch Linux помечает подобные зависимости как «необязательные», что избавляет пользователя от проблем, приведённых в пример выше, но требует от него определённых знаний. То есть, если утрировать, то рабочий стол без почтовой программы работает, но кому-то может понадобиться её функционал. Таким образом, пользователь должен знать какие необязательные зависимости ему нужны, а какие нет. Большинство же дистрибутивов решают это за пользователя, имея в зависимостях того или иного пакета максимальный набор компонентов «на все случаи жизни». Другими словами, чем меньше знаний требуется для использования дистрибутива, тем больше в нём «мусора». И чем больше опыта у пользователя, тем сложнее его «настольный» дистрибутив. По той же причине в мире существует огромное количество различных дистрибутивов, ориентированных на различную аудиторию. Но не всегда широта возможностей прямо пропорциональна сложности.

Исторически так сложилось, что большая часть пакетов в Linux зависит от наличия системных библиотек. По аналогии с директорией «system32» в Windows, в Linux есть директория «lib». Такой подход экономит место, когда одна и та же системная библиотека используется множеством программ, но он же делает пакеты одного дистрибутива непригодным для установки в другой. Кроме имён системных библиотек отличаются так же их версии, в зависимости от дистрибутива. Во многих пакетах в качестве зависимостей указаны не только сами библиотеки, но и их версии. По той же причине многие дистрибутивы не обновляют версии ПО в пределах жизненного цикла версии дистрибутива. Например, в Debian вы будете получать обновления безопасности, но версии практически всего ПО останутся неизменными. Таким образом ряд дистрибутивов поддерживает стабильность. Тот же подход можно видеть в корпоративных версиях Windows, когда весь функционал заморожен в пределах одной версии, и обновления содержат только исправления и патчи безопасности. Но в Windows это касается только компонентов ОС, тогда как всё остальное устанавливается и обновляется отдельно. В Linux же всё прикладное ПО распространяется централизованно, как и компоненты ОС. Теоретически новая версия определённой программы будет работать с текущей версией определённой системной библиотеки, так же, как и текущая версия программы с более новой библиотекой, но это не тестировалось на пререлизных стадиях дистрибутива. Всегда есть шанс, что что-то пойдёт не так. Поэтому в ряде дистрибутивов есть стадия так называемой «заморозки», когда перед релизом все версии ПО замораживаются и остаются неизменными на протяжении всего жизненного цикла версии дистрибутива. Такой подход даёт свои результаты. Если не использовать сомнительные сторонние репозитории в Debian, то она гораздо стабильнее даже корпоративных версий Windows. Некоторые дистрибутивы могут сочетать в себе стабильность и инновации. То есть, они устанавливают рань между новизной ПО и его стабильностью на более приемлемой для широкого круга пользователей позиции. Роллинг-дистрибутивы так же могут быть стабильными, если разработчики и тестировщики приложили к этому достаточно усилий.

Понятно, что «пакетно-зависимый» подход не всегда оправдывает себя. Попытки унификации пакетов ПО для Linux были всегда. Две самые удачные и современные системы – это Snap от Canonical и Flatpak, которая разрабатывается сообществом. Обе системы не идеальны, но позволяют решить две самые основные задачи: унификация и интеграция. В отличии от более ранних реализаций, установленное таким образом ПО смотрится нативно и интегрировано в систему (ОС знает, что оно установлено, присутствуют все привычные меню, ярлыки и прочее). Основным плюсом является то, что подобный пакет содержит все необходимые зависимости и работает на любом дистрибутиве, способом работать с этой системой пакетов. Разработчикам не нужно разбирать зависимости каждого дистрибутива при создании пакета. Нужно лишь учитывать специфику самой системы Snap или Flatpak. А то, как система в целом работает в дистрибутиве – это дело разработчиков дистрибутива. Как уже было сказано, Snap и Flatpak не идеальны. По ряду причин ПО не всегда выглядит нативно и не всегда учитывается всё возможное. Это зависит как от самих этих систем, так и от интеграции системы на стороне дистрибутива. Но обе системы развиваются и, на мой взгляд, это шаг в правильном направлении, хотя обе системы часто критикуются. В основном критика относится к проприетарной природе серверной части Snap и тому факту, что в Ubuntu, при установке ПО через графический интерфейс, приоритет отдаётся пакетам Snap. Так же критикуется «Windows-подход» при распространении ПО подобным способом. Последнее относится, в основном, к размеру и нагрузке. Размер этих пакетов значительно выше традиционных пакетов, так как каждый пакет содержит все необходимые зависимости локально, и их наличие или отсутствие в системе во внимание не берётся. Но при объёмах современных носителей информации лишний десяток гигабайт менее важен, чем унификация пакетов в Linux.

Для управления пакетами Snap и Flatpak используются их собственные пакетные менеджеры, но многие «традиционные» пакетные менеджеры имеют плагины для работы с этими пакетами.

И так, если с зависимостями и различиями в дистрибутивах всё более или менее ясно, то при чём тут командная строка? Дело всё в той же централизованной системе. При обновлении пакетов, в системе часто обновляются и компоненты рабочего стола, и сам пакетный менеджер. Чем меньше компонентов задействовано в процессе обновления, тем меньше шансов на то, что что-то пойдёт не так. Графический интерфейс для всех пакетных менеджеров – это всего лишь «надстройка». Если установка и удаление пакетов обычно проходит гладко, то при использовании консоли у вас больше возможностей решить ту, или иную проблему, возникшую во время обновления. Особенно это актуально в роллинг-дистрибутивах, где со временем обновляется не только само ПО, но и список его зависимостей. Графический интерфейс может повиснуть при обновлении его компонентов, консоль же менее зависит от окружения рабочего стола, даже если является его частью. Не важно как вы обновляете Snap-пакеты или Flatpak-пакеты, так как они не затрагивают систему, но в остальных случаях обновляться через консоль безопаснее.
В Сети часто можно найти инструкции по сборке того или иного из исходного кода и последующей установке (команда make install), но это плохая идея в пакетных дистрибутивах, где пакетный менеджер – основной и часто единственный инструмент контроля и управления программным обеспечением. Даже в Gentoo, где всё собирается из исходников, есть свои инструменты контроля. В пакетных же дистрибутивах правильным будет собрать пакет и установить его с помощью пакетного менеджера. Исключение можно сделать для чего-то локального, установленного в один отдельный каталог с правами пользователя. Ручное «размазывание» библиотек по системным разделам – плохая идея, так как рано или поздно возникнут проблемы.

И так, резюмируя всё вышесказанное… Пакетные менеджеры в Linux существуют не только для удобства. Они ведут учёт ПО и обеспечивают правильность его установки, от чего зависит стабильность работы как самого ПО, так и операционной системы в целом. Установка ПО другими способами возможна, но с рядом оговорок. На самом деле, подобный подход кажется странным только тем, кто много лет просидел на Windows. В Windows так же есть эксперименты с пакетными менеджерами, но проприетарная модель как самой ОС, так и большей части программ под неё, не позволяет добиться той же слаженности, что мы видим в операционных системах на ядре Linux.
Like Dislike

___
Tatyana K.



Tags: Linux


 
  • Creative Commons Licence
  • Norton Safeweb
  • Powered by MariaDB
  • Powered by Debian
  • Website Uptime Monitoring By ServiceUptime.com
  • Yandex.Metrika