Дистрибутив Linux

Linux как набор программных продуктов. DVD-9 — это 9 млн килобайтов, примерно 4 тысячи программных продуктов. Или 8. Тысяч. Следовательно, из сети не ещё какие-то программы надо добывать (их и так полно), а информацию. Это полностью отличается от правовладельческих принципов: одна программа — один диск.

Дистрибутив — коллекция ПО, следующая строгой дисциплине, строгость и удобство зависит от организаторов дистрибутива.

Сложнее при создании ПО: надо совместно тестировать, притирать программы и т. п., проще при использовании: гарантированное соответствие версий, очень мало места

Архив с удобствами

Если надо, можно поставить «чужой» .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, Red hat Package Manager. ПРограмма для работы с одним пакетом. Основная задача — установка или удаление пакета. Он умеет проверить целостность пакета в файле (это робот, который собирал пакет в Сизифе, его подписал), проверить зависимости (не стоит устанавливать пакет, игнорируя зависимости, хуже всего, если он тогда заработает), проверить целостность установленного пакета (модифицированный файл: несовпадение контрольной суммы, даты модификации и размера), удалить пакет.

Два пакета одинакового ПО, но разных версий нужны крайне редко. Тогда различие в версиях вносится в имя пакета, например, gtk1 и gtk. А просто два пакета разных версий установить нельзя, и это хорошо, так как соблюдается чистота версий.

При удалении поправленный файл не удалился, так как он не помечен в пакете, как конфигурационный.

Вопрос: а зачем к iso-образу прилагается отдельный файл с md5-контрольной суммоу? Контрольная сумма приходит с пакетом, там предусмотрено. А в iso — не предусмотрено, надо прилагать отдельно. Запускаете md5sum файл и сравниваете.

Установщик не устанавливает пакеты, которые ему не указали, например, по зависимостям. Почему? Потому что неизветсно, откуда их брать, эти пакеты «по зависимостям».

Диспетчер пакетов

В ALT Linux используется установщик RPM и диспетчер APT (Advanced Packaging Tool). Это унакльное сочетание популярного установщика и технологичного диспетчера.

Диспетчер работает с хранилищами пакетов. Например, локальное хранилище на диске, дистрибутив в сети, обновления по безопасности к дистрибутиву, новое ПО для старого дистрибутива (т. н. 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 для Сизифа и положить его туда, пользоваться им будет легко и сообщество поможет.

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

Главы учебника

Получается, что проще всего участвовать в театировании или создании дистрибутива!