> Лекция седьмая -- Пакеты в дистрибутиве Linux > Дистрибутив Linux Linux как набор программных продуктов. DVD-9 -- это 9 млн килобайтов, примерно 4 _тысячи_ программных продуктов. Или 8. _Тысяч_. Следовательно, из сети не ещё какие-то программы надо добывать (их и так полно), а информацию. Это полностью отличается от правовладельческих принципов: одна программа -- один диск. Дистрибутив -- коллекция ПО, следующая строгой <дисциплине>, строгость и удобство зависит от организаторов дистрибутива. . У каждого пакета есть свой <сопровождающий> -- человек, входящий в сообщество _дистрибутива_ и в сообщество ползователей (или разработчиков) программного продукта. . Использование общего <хранилища>. Каждый сопровождающий складывает свой пакет в хранилище, если считает его готовым. . <Сборка> ПО из исходного текста (вместе с правилами сборки и исправлениями), в хранилище сборка автоматическая . <Свободный> доступ к исходным текстам ПО, следовательно, эти исходные тексты можно исправлять, если найдена ошибка . <Совместное> тестирование (в идеале -- всех) программ: выпуск публично доступных бета-версий и тестирование ``всем миром'' . <Стандарт> на размещение файлов (FHS) -- условие соседства ПО в одном дистрибутиве, мы точно знаем, где что лежит и можем отследить конфликты Сложнее при создании ПО: надо совместно тестировать, притирать программы и т. п., проще при использовании: гарантированное соответствие версий, очень мало места > Архив с удобствами . Программа состоит _не_ из одного файла, следовательно, нужен архив . Информация: время сборки, время установки, сопровождающий, лицензия, сайт проекта, краткое описание, достаточное описание и т. п. . Мы должны отразить в системе (``зарегистрировать''), какие файлы входят в пакет, для удобного удаления и отслеживания конфликтов по именам файлов. хранится контрольная сумма файлов для того, чтобы понять, изменился файл или нет. Если к файлу прилагается тип ``настроечный'', то при удалении пакета изменённый файл не удаляется, а переименовывается, а при обновлении пакета новый настроечный файл устанавливается с другим именем, если есть изменённый старый. . Если при установке или удалении пакета необходимо что-то _сделать_ (изменить некий настроечный файл, остановить или стартовать службу, перегенерировать какой-нибудь список, например, меню оконного менеждера), то в архив складываются программы (как правило, сценарии на sh), которые _запускаются_ при старте или удалении пакета. Пакт -- это не просто архив, а архив, при манипуляции с котороым может выполняться какая-нибудь программа. Например, после кустановки пакета надо обновить менб оконного менеждера, это делается не чудесным образом, а post-install-сценарием . Следствие: _единая_ прозрачная система установки (а не много разных!); этьо потому, что программы из пакетов используются _вместа_ и доступ к ним свободный Если надо, можно поставить ``чужой'' ^.rpm^ или пакет ^.deb^ в ALT Linux, только вероятность, что он заработает, ниже ^100%^, потому что ``неродной'' и, возможно, потребуюстя некие условия для работы, которых нет. > Зависимости и конфликты -- 1 Что такое библиотеки и разделяемые библиотеки? В проргамме, скорее всего, используется много подпрограмм (стандартных, вроде работы с граыикой, файлами, мультимедиа и т. п.). Эти подпрограммы написаны не авторами данного ПО, а другими людьми как сборники функция для работы с чем-либо. Даже исходного кода от них может не быть, так как при сборке прграммы достаточно скомпоновать на этапе редактирования связей (``слинковать'') эти функции с основной программой, и они будут вызываться и работать. Функции собраны в т. н. <библиотеки|библиотека> для удобства использования. Есл программ, использующих функцию из данной библиотеки, много, удобнее не прикомпоновывать код функции к программе, а оставить его в библиотеке особого вида -- <разделяемой|разделяемая библиотека>. при запуске первой программы библиотека загружается в память, и программа пользуется функциями оттуда. При запуске других программ используется та же самая библиотека в памяти, новых не загружается. Тем самым экономится память и вежётся эффективная борьба с разноверсицей. Это по-настоящему возможно только при свободном доступе ко всем билбиотекам, а подгонка старой программы под новую библиотеку -- только при свободном доступе к исходным текстам. В ``классический'' пакет прикладных программ: исполняемые файлы, настройки, разделяемые библиотеки, утилиты и всякие дополнения. Это внушительный набор, более всего напоминающий этот LiveCD, полный набор программ для решения какой-то задачи. Чего _не_ должно быть в пакете Linux (что надо выделить в отдельный пакет, чтобы его содержимое можно было использовать независимо от какого-либо конкретного ПО): общие утилиты и разделяемые библиотеки, а также часть, которые могут не понадобиться, например, дополнения (plug-ins). Мы не можем использовать _один_ ``неполный'' пакет, для полноты необходимо поставить ещё несклько пакетов. Например, без библиотек программа вообще не заработает. Появляется понятие <зависимость|>. > Зависимости и конфликты -- 2 Для того, чтобы установить пакет, скажем, ^xpdf^, нужны пакеты ^fonts-type1-urw^, ^urlview^, ^xpdf-reader^ и ^xpdf-utils^, иначе он ``не заработает''. А вот пакету ^xpdf-reader^ нужны _файлы_ (всякие библиотеки -- гафические, работа со шрифтами, c++ и пр.), файл ^/bin/sh^ и т. п. Неважно, какому пакету эти файлы принадлежат. Если неизвестно или неважно, как _называется_ конкретный файл или конкретный пакет, а нужно, чтобы он делал что-то определённое, нельзя поставить зависимость ни на пакет, ни на файл. Например, для web-почты требуется imap-сервер, любой, но чтобы был. что делать? Договориться, чтобы свойство ``делать что-то определённое'' называлось одинаково и упоминалось в поле ^Provides:^ всех пожходящих пакетов, например, ^Provides: imapd^ во всех пакетах с imap-серверами. И потребовать в зависимостях веб-почты этот _псевдопакет_ imapd. Или так: любой из vi-образных текстогвых редакторов (elvis, vim, nvi) предоставляет ^Provides: vi^, и если требуется, чтобы был установлен какой-нибудь vi, именно на псевдопакет ^vi^ ставится зависимость. Итак, один пакет зависит от пяти других, каждый из пяти -- от полдюжины третьих, получается дерево (строго говоря, ориентированный граф) зависимостей пакетов друг от друга. Это хорошо: невероятная (размер пакета может быть несколько килобайтов!) экономия места, использование одной и той же библиотеки и/или утилиты всеми другими (быстрее находятся ошибки, меньше ошибок остаётся), совместнапя разработка. Внутри дистрибутива очень удобно. Это плохо, если цепочка зависимости нарушена (например, при использовании хранилища, пакеты в котором _начали_ обновляться, новые зависят от новых, а старые -- от старых, или при скачивании бинарных пакетов неизвестно откуда). Хуже всего дело обстоит с правовладельческими прогарммами -- неизвестно с какими библиотеками, неизвестно как собранными. Есть такие пакеты -- метапакеты или виртуальные пакеты, -- в которых вообще ничего нет, никаких файлов. Одни зависимости. Просто ставишь один пакет, а по зависимостям ставится целое дерево. Например, ^xpdf^ (^xpdf-utils^ и ^xpdf-reader^) или ^xorg-x11^ (много пакетов в сзависимостях, неткороые из них -- тоже метапакеты). Альтернативы: слегка разные пакеты с одинаковыми файлами или одинаковой функциональностью. Например, ^xpdf^ и ^xpdf^, модифицированный для поддержки японского (старые программы плохо поддерживают двухбайтовые кодировки, их надо править). Или, допустим, два imap-демона, ведь их нельзя запустить одновременно. Например, есть links, а есть elinks. Это похожие программы. При установке _ни один_ файл не называется ^/bin/links^: ^/bin/elinks^ и ^/bin/links-classic^, а ^/bin/links^ -- это символьная ссылка на один из файлов, управляемая утилитами из пакета ^alternatives^. По умолчанию она указывает на альтернативу с большим приоритетом, но можно переключить. Или ^xvt^ -- это ссылка либо на ^xterm^ (приортет 40), либо на ^aterm^ (50), значит, если нисего не трогать и установить оба пакета, по команде ^xvt^ запустится ^aterm^. > Установщик пакетов Пример <установщика|установщик пакетов> -- RPM, _R_ed hat _P_ackage _M_anager. ПРограмма для работы с _одним_ пакетом. Основная задача -- установка или удаление пакета. Он умеет проверить целостность пакета в файле (это робот, который собирал пакет в Сизифе, его подписал), проверить зависимости (не стоит устанавливать пакет, _игнорируя_ зависимости, хуже всего, если он тогда заработает), проверить целостность установленного пакета (модифицированный файл: несовпадение контрольной суммы, даты модификации и размера), удалить пакет. Два пакета одинакового ПО, но _разных_ версий нужны крайне редко. Тогда различие в версиях вносится в _имя_ пакета, например, gtk1 и gtk. А просто два пакета разных версий установить нельзя, и это хорошо, так как соблюдается чистота версий. При удалении поправленный файл не удалился, так как он не помечен в пакете, как конфигурационный. Вопрос: а зачем к iso-образу прилагается отдельный файл с md5-контрольной суммоу? Контрольная сумма приходит с пакетом, там предусмотрено. А в iso -- не предусмотрено, надо прилагать отдельно. Запускаете ^md5sum {файл}^ и сравниваете. Установщик не устанавливает пакеты, которые ему не указали, например, по зависимостям. Почему? Потому что неизветсно, откуда их брать, эти пакеты ``по зависимостям''. > Диспетчер пакетов В ALT Linux используется установщик RPM и диспетчер APT (_A_dvanced _P_ackaging _T_ool). Это унакльное сочетание популярного установщика и технологичного диспетчера. Диспетчер работает с _хранилищами_ пакетов. Например, локальное хранилище на диске, дистрибутив в сети, обновления по безопасности к дистрибутиву, новое ПО для старого дистрибутива (т. н. backports), нестабильное хралилище самого нового (Сизиф). Не нужно скачивать все файлы хранилища, нужны только индексы (вся информация о пакетах), размеры индексов на несколько порядков меньше общего размера хранилища, по индексам можно искать с помощью ^apt-cache search^, пакет может быть не установлен и вообще быть где-то в сети. Устанавливать и удалять пакеты можно рекурсивно: установить надо один, а APT по зависимостям вычислит, какие ещё требуются пакеты, и притащит их из хранилища, и тоже установит. При удалении APT удалит вдобавок все пакеты, зависящиее от данного, да ещё и спросит, точно ли вы этого хотите. А если вы пытаетесь удалить что-то очень важное, например, ядро или coreutils, то APT попросит ввести целую фразу, что-то вроде ``Yes, do as I say!''. Удалить все пакеты, которые были установлены _только_ по зависимостям, нельзя. Пробовали вводить такую практику: пакет помечается как установленный только по зависимостям, если его явно не просили установить. И если от него ни один пакет не зависит в какой-то момент, он удаляется. Но тогда надо при установке указывать все пакеты, которые вы хотите установить, пропадает смысл метапакетов, стновится муторно работать. А если не вводить такого автоматизма, всё возвращается обратно: удалять этот конкретно ``лист'' дерева пакетов (то есть пакет, от которого никакой другой не зависит), или нет? Поэтому игрища с массовой многократной установкои и удалением пакетов кончаются тем, что на машине оказываются почти все библиотеки из хранилища. Диспетчер _доставляет_ пакеты из хранилища -- скачивает, копирует и т. п. Даже если пакеты лежат в файловой системе (например, на сетевом диске) их можно _сначала_ скопировать куда-то в ^/var^, а затем только установить. Установщик этого не умеет, не умеет определять, как доставить пакет на машину. Сумма всего сказанного -- это _обновление_ пакетов из хранилища. То есть на машине -- более старые версии пакетов, в хранилище -- более новые. Диспетчер (^apt-get dist-upgrade^) проверяет, какие пакеты надо обновить, хватает ли зависимостей для обновления (то есть есть ли ф хранилищах или на машине пакеты, которые потребуются после обновления), не надо ли что-либо _удалить_ (например, из-за конфликта или потому что один пакет был явно заменён другим с помощью ^Deprecates:^), доставляет новые пакеты и устанавливает их вместо старых (не ``поверх'', и не ``удаляет старые, устанавливает новые'', а именно ``уствнавливает вместо'', есть различиая небольшие). > Где и как искать программу Задача установки определённого пакета встаёт нечасто. Гораздо чаще надо _подобрать_ ПО для решения определённой _задачи_. Как и где найти? || Может, нужный пакет уже установлен? || Есть команды поиска по информационному пространству Linux: ^apropos^, ^info --apropos^, ^grep -r "{что-то}" /usr/share/doc^ || || Скорее всего, пакет есть в дистрибутиве || ^apt-cache search {что-то}^ или поиск в Сети упоминания пакета, а потом поиск его в дистрибутиве || || Пакет есть в нестабильном хранилище (Сизифе), но нет в дистрибутиве || А нет ли его в backports? Есть ли смысл переходить на Сизиф в качестве основного источника пакетов? || || На сайте производителя есть какой-то RPM || Скачать, установить и надеяться на лучшее || || На сайте производителя есть какой-то ``установщик'' || Задуматься над тем, как вы будете всё это удалать. Скачать, установить и надеяться на лучшее || Чем ниже по таблице, тем сложнее. Возможно, проще будет самому изготовить пакет. || Нет пакета под дистрибутив, есть в Сизифе || Сделать backport из пакета в Сизифе (пересобрать в окружении дистрибутива). Это может не потребовать никаких усилий (всё соберётся автоматом), потребовать каких-то дополнительных правок или дополнительных backport, а может и не получиться, если новое ПО написано в рассчёте на слишком новые библиотеки или ядро || || Имеется src.rpm на сайте производителя || Можно собрать _нестандартный_ RPM (по правилам не ALT, а производителя), но он норомально установится и будет использовать дистрибутивные библиотеки. А можно собрать и стандартный для ALT, слекга поправив spec-файл в соответствие с дисциплиной. Положите в своё локульное хранилище и пользуйтесь! || || Есть какие-то исходники || Не верьте, что configure-make-make install -- это легко и удобно. Крибле-крабле-бумс почти никогда не работает как надо. Всё равно придётся проверить, нет ли конфликтов, правильно ли устанавливается, править исходники и пр. А уж если эту программу надо обновлять, устанавливать на _нескольких_ машинах и т. п., то не сделав пакета вы сильно _усложните_ себе жизнь. || Следствие: _надёжнее_ всего сделать RPM для Сизифа и положить его туда, пользоваться им будет легко и сообщество поможет. Итого: лучше всего пользоваться дистрибутивным пакетом и только в крайнем случае скачивать готовый либо изготавливать дистрибутивный же пакет, а только в крайнем случае делать не пакет, а бинарную установку напрямую. > Главы учебника Получается, что проще всего _участвовать_ в театировании или создании дистрибутива!