Linux как набор программных продуктов. DVD-9 — это 9 млн килобайтов, примерно 4 тысячи программных продуктов. Или 8. Тысяч. Следовательно, из сети не ещё какие-то программы надо добывать (их и так полно), а информацию. Это полностью отличается от правовладельческих принципов: одна программа — один диск.
Дистрибутив — коллекция ПО, следующая строгой дисциплине, строгость и удобство зависит от организаторов дистрибутива.
Сложнее при создании ПО: надо совместно тестировать, притирать программы и т. п., проще при использовании: гарантированное соответствие версий, очень мало места
Если надо, можно поставить «чужой» .rpm или пакет .deb в ALT Linux, только вероятность, что он заработает, ниже 100%, потому что «неродной» и, возможно, потребуюстя некие условия для работы, которых нет.
Что такое библиотеки и разделяемые библиотеки? В проргамме, скорее всего, используется много подпрограмм (стандартных, вроде работы с граыикой, файлами, мультимедиа и т. п.). Эти подпрограммы написаны не авторами данного ПО, а другими людьми как сборники функция для работы с чем-либо. Даже исходного кода от них может не быть, так как при сборке прграммы достаточно скомпоновать на этапе редактирования связей («слинковать») эти функции с основной программой, и они будут вызываться и работать. Функции собраны в т. н. библиотеки для удобства использования.
Есл программ, использующих функцию из данной библиотеки, много, удобнее не прикомпоновывать код функции к программе, а оставить его в библиотеке особого вида — разделяемой. при запуске первой программы библиотека загружается в память, и программа пользуется функциями оттуда. При запуске других программ используется та же самая библиотека в памяти, новых не загружается.
Тем самым экономится память и вежётся эффективная борьба с разноверсицей. Это по-настоящему возможно только при свободном доступе ко всем билбиотекам, а подгонка старой программы под новую библиотеку — только при свободном доступе к исходным текстам.
В «классический» пакет прикладных программ: исполняемые файлы, настройки, разделяемые библиотеки, утилиты и всякие дополнения. Это внушительный набор, более всего напоминающий этот LiveCD, полный набор программ для решения какой-то задачи.
Чего не должно быть в пакете Linux (что надо выделить в отдельный пакет, чтобы его содержимое можно было использовать независимо от какого-либо конкретного ПО): общие утилиты и разделяемые библиотеки, а также часть, которые могут не понадобиться, например, дополнения (plug-ins).
Мы не можем использовать один «неполный» пакет, для полноты необходимо поставить ещё несклько пакетов. Например, без библиотек программа вообще не заработает. Появляется понятие зависимость.
Для того, чтобы установить пакет, скажем, 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 для Сизифа и положить его туда, пользоваться им будет легко и сообщество поможет.
Итого: лучше всего пользоваться дистрибутивным пакетом и только в крайнем случае скачивать готовый либо изготавливать дистрибутивный же пакет, а только в крайнем случае делать не пакет, а бинарную установку напрямую.
Получается, что проще всего участвовать в театировании или создании дистрибутива!