Linux book/Install and configure
Материал из eSyr's wiki.
(→Конфликты версий) |
|||
| Строка 34: | Строка 34: | ||
* Искать в репозитории | * Искать в репозитории | ||
* Искать в чужом дистрибутиве. | * Искать в чужом дистрибутиве. | ||
| - | * Поиск по специализированным сайтам (sourceforge, | + | * Поиск по специализированным сайтам ([http://sourceforge.net/ sourceforge], savannah (http://savannah.gnu.org/, http://savannah.nongnu.org/), [http://freshmeat.net/ freshmeat]) |
| - | * Поиск в google на предмет сайта разработчика | + | * Поиск в [http://google.com google] на предмет сайта разработчика |
* Если всё это проделали, и результатов нет, то не значит, что приложения не существует. Очень хороший источник информации — сообщество. | * Если всё это проделали, и результатов нет, то не значит, что приложения не существует. Очень хороший источник информации — сообщество. | ||
** Официальные информационные ресурсы (документация, сайт, wiki) | ** Официальные информационные ресурсы (документация, сайт, wiki) | ||
| Строка 53: | Строка 53: | ||
=== FHS === | === FHS === | ||
| - | В Linux существует строгая иерархия каталогов (File Hierachy System, FHS), которая описывает структуру каталогов и их семантику. Подробно FHS описан в учебнике Курячего Г. В. «Операционная система Linux». Так, в соответствии с FHS, существует 4 места для ПО, 2 каталога для разделяемых библиотек, 1 каталог для документации, и так далее. Каждая программа, состоящая из многих файлов, размещает их в соответствии с их предназначением в соответствующие каталоги в ФС. | + | В Linux существует строгая иерархия каталогов (File Hierachy System, FHS), которая описывает структуру каталогов и их семантику. Подробно FHS описан в учебнике Курячего Г. В. [http://uneex.ru/Books/LinuxIntro «Операционная система Linux»]. Так, в соответствии с FHS, существует 4 места для ПО, 2 каталога для разделяемых библиотек, 1 каталог для документации, и так далее. Каждая программа, состоящая из многих файлов, размещает их в соответствии с их предназначением в соответствующие каталоги в ФС. |
Пример размещения некоторых типичных файлов абстрактной программы: | Пример размещения некоторых типичных файлов абстрактной программы: | ||
| Строка 61: | Строка 61: | ||
И всё это входит в один программный продукт. | И всё это входит в один программный продукт. | ||
| - | + | В Linux достаточно аккуратно проделано разделение прав доступа, и пользователь не имеет права доступа на запись к большей части файловой системы (за исключением своей домашней директории и /tmp/). Тем не менее, процессы, запущенные под суперпользователем игнорируют ограничения доступа. Поэтому установка ПО обычно делается под root'ом (поскольку при этом создаются файлы в каталогах, которые закрыты на запись для простых пользователей), и установку программ, кроме как в свой каталог, обычный пользователь, в отличие от root'а, осуществить не может. | |
| - | + | ||
=== Пакет === | === Пакет === | ||
| Строка 77: | Строка 77: | ||
В связи с этим возникает ряд вопросов: | В связи с этим возникает ряд вопросов: | ||
| - | * | + | * Что делать, если одни пакеты зависят от других (например, один программный продукт и использует в своей работе другой)? |
* Как разрешать конфликты, то есть, те случаи, когда при попытке установить файл из архива оказывается, что такой файл есть, и создан он не пользователем, а другим пакетом? | * Как разрешать конфликты, то есть, те случаи, когда при попытке установить файл из архива оказывается, что такой файл есть, и создан он не пользователем, а другим пакетом? | ||
| Строка 94: | Строка 94: | ||
Но, при всех достоинствах разделяемых библиотек, появляется проблема -- задача разрешения зависимостей. Разделяемые библиотеки не входят в пакет. Каждая группа библиотек находится в отдельном пакете. Перед установкой программного продукта необходимо установить все библиотеки, которые им используются, то есть, удовлетворить его зависимости. Получается палка о двух концах: с одной стороны, использование разделяемых библиотек упрощает и ускоряет разработку; с другой стороны, усложняется порядок установки программ — необходимо скачать и установить в правильном порядке всё дерево (точнее, ациклический орграф) зависимостей. В большинстве дистрибутивов Linux для автоматизации удовлетворения зависимостей существуют две программы — установщик и менеджер пакетов, которые подробно рассмотрены далее. | Но, при всех достоинствах разделяемых библиотек, появляется проблема -- задача разрешения зависимостей. Разделяемые библиотеки не входят в пакет. Каждая группа библиотек находится в отдельном пакете. Перед установкой программного продукта необходимо установить все библиотеки, которые им используются, то есть, удовлетворить его зависимости. Получается палка о двух концах: с одной стороны, использование разделяемых библиотек упрощает и ускоряет разработку; с другой стороны, усложняется порядок установки программ — необходимо скачать и установить в правильном порядке всё дерево (точнее, ациклический орграф) зависимостей. В большинстве дистрибутивов Linux для автоматизации удовлетворения зависимостей существуют две программы — установщик и менеджер пакетов, которые подробно рассмотрены далее. | ||
| - | Кроме этого существуют непрямые зависимости. Возможна ситуация, когда для работы вашего продукта другой программный продукт не является необходимым, но с ним связана некая некритичная функциональность. Например, для почтового | + | Кроме этого существуют непрямые зависимости. Возможна ситуация, когда для работы вашего продукта другой программный продукт не является необходимым, но с ним связана некая некритичная функциональность. Например, для почтового веб-сервера не обязательно нужен почтовый сервер, поэтому установка почтового сервера не должна требоваться, но его можно оформить как рекомендованный пакет, поскольку первое без второго используется редко. |
==== Конфликты ==== | ==== Конфликты ==== | ||
| Строка 105: | Строка 105: | ||
Существует метод, позволяющий разрешать конфликты — альтернатива. Для каждого пакета выбираются свои уникальные имена (в данном примере — /usr/bin/vi.original, /usr/bin/vim, /usr/bin/mvi). Кроме этого, создаётся файл с конфликтным именем (/usr/bin/vi), но он является символической ссылкой на один из файлов, боровшихся за данное имя. То, куда будет указывать символическая ссылка, решается при помощи отдельного механизма(например назначением пакетам некоторых весов и ссылкой на файлы пакета с наибольшим весом). | Существует метод, позволяющий разрешать конфликты — альтернатива. Для каждого пакета выбираются свои уникальные имена (в данном примере — /usr/bin/vi.original, /usr/bin/vim, /usr/bin/mvi). Кроме этого, создаётся файл с конфликтным именем (/usr/bin/vi), но он является символической ссылкой на один из файлов, боровшихся за данное имя. То, куда будет указывать символическая ссылка, решается при помощи отдельного механизма(например назначением пакетам некоторых весов и ссылкой на файлы пакета с наибольшим весом). | ||
| - | |||
| - | ==== Конфликты версий ==== | ||
| - | о_О | ||
| - | кто здесь ? | ||
=== Установщик пакетов === | === Установщик пакетов === | ||
| - | Как сказано выше, единицей ПО считается пакет | + | Как сказано выше, единицей ПО считается пакет. Пакет обладает массой свойств — это не только распаковка, но и регистрация в системе, запуск некоторых сценариев при установке/удалении. Работой с отдельным пакетом занимается установщик. |
'''Установщик''' — утилита, которая позволяет управлять отдельным пакетом. Сюда входят установка и удаление, проверка пакета на различные свойства, просмотр различий в версиях пакета, проверка зависимостей, и так далее. | '''Установщик''' — утилита, которая позволяет управлять отдельным пакетом. Сюда входят установка и удаление, проверка пакета на различные свойства, просмотр различий в версиях пакета, проверка зависимостей, и так далее. | ||
| + | |||
| + | По историческим причинам, в список обязаннстей установщика пакетов входит также их сборка пакетов из их исходных версий. В исходную версию пакета (src package) входит вся инфрмация, необходимая для его сборки. | ||
| + | |||
| + | Важно отметить, что установщик пакетов работает только с отдельными файлами, а не с репозиторием. Этот факт подробнее будет рассмотрен далее. | ||
| + | |||
| + | На данный момент существует определённое количество форматов пакетов и утилит по работе с ними. Наиболее популярными являются два следующих формата: | ||
| + | * RPM, RedHat Package Manager. Изначально появился в дистрибутиве RedHat. На данный момент используется в большом колоичестве RedHat-based (и не только) дистрибутивов, в число которых (косвенно, посредством Mandrake Linux) входит и ALT Linux. Установщиком для данного формата пакетов является дноимённая утилита rpm<ref>. | ||
| + | * DEB, Debian software package. | ||
| + | |||
| + | Система установки, чборки пакетов --- RedHat Package Manager. Это установщик пакетов, утилита, которая работае т ровно с одним пакетом, лежащим ровно в одном файле. Например: | ||
| + | * rpm -i <file>.rpm --- установка | ||
| + | * rpm -e <file>.rpm --- удаление | ||
| + | В подтверждение того, что rpm --- архив? tcnm утилита-фильтр rpmtocpio, которая выводит файл в формате cpio. Можно его посмотреть, написав rpmtocpio | cpio -itv. | ||
| + | |||
| + | Все перечисленные свойства RPM поддерживает. | ||
| + | |||
| + | С помощью rpm можно собрать пакет. Идея состоит в следующем: что нужно, чтобы собрать пакет? Для начала нужно иметь в виду одну особенность: авторы программ знать-не знают, ведать-не ведают о существовании дистрибутива ALT Linux, и правилах структуры пакетов. | ||
| + | Например, есть утилита eaglomode, которая устанавливается а-ля солярис: /opt/eaglemode/{bin|lib|res|etc}. ... | ||
| + | |||
| + | Это значит, что нужно модифицировать исходный код продукта, в помощь чему есть набор утилит patch, поскольку ментейнер не делает изменения с 0 для каждой версии, он оформляет эти изменения в виде патча, который потом накладывается. | ||
| + | |||
| + | Нужно соблюсти три условия: | ||
| + | * Оформить отличия в виде патчей | ||
| + | * Написать команды по сборке | ||
| + | * Нужно организовать предустановочный и послеудалятельный суенарий | ||
| + | * Заполнить паспорт пакета | ||
| + | |||
| + | Для всего это есть один файл, спекфайл, в которым всё это лежит, за исключением больших файлов, которые лежат отдельно. Иговорится, что пакеет состоит из скачанного исходника, спекфайла и дополнительных фйайлов. Это составляет src.rpm. Из этого собирается rpm. | ||
| + | |||
| + | Появляется второе понятие зависимости: зависимости, необходимые для сборки пакета. | ||
| + | |||
| + | Из этого можно сделать вывод, что rpm для обычного пользователя программа не очень удобная. Поскольку при попытке установить покет может оказаться, что не удовлетворены изх зависимости, для них не удовлетворены их и так дале. Причём rpm не может отследить их все, они в пакете не написаны, там только непосредственные зависимости. Но со своей задачей rpm справляется. | ||
| + | |||
=== Менеджер пакетов === | === Менеджер пакетов === | ||
| Строка 120: | Строка 149: | ||
По традиции, установщик также используется для сборки пакета. Но это не столь важно, сколь другая особенность установщика: он работает с одним файлом, а для управления всеми доступными пакетами необходим диспетчер (менеджер) пакетов, который работает сразу с хранилищами пакетов. В итоге, задача диспетчера состоит в построении графа зависимостей, разрешения вопроса о получении недостающих пакетов (скачивания их из доступных источников) и их установке. | По традиции, установщик также используется для сборки пакета. Но это не столь важно, сколь другая особенность установщика: он работает с одним файлом, а для управления всеми доступными пакетами необходим диспетчер (менеджер) пакетов, который работает сразу с хранилищами пакетов. В итоге, задача диспетчера состоит в построении графа зависимостей, разрешения вопроса о получении недостающих пакетов (скачивания их из доступных источников) и их установке. | ||
| - | !!! Тут переход от определений к тому, откуда ставить, и что за это будет | ||
| + | Поэтому для решения этих задач используется диспетчер пакетов. В альте используется apt? Advanced Package Tool. Он взят из дебиавна, в котором ещё и свой формат пакетов --- dpkg. Он был достаточно универсален, чтобы после нескольких ударов кувалдой он начинал использовать rpm. Причём его писали такие хакеры, что можно и кувалду сломать. | ||
| + | |||
| + | Мы уже описали ситуацию, пр и которой установщик пасует. Что же ... . | ||
| + | * Пользователь совершенно не обязан указывать версию пакета. Откула apt узает версию пакета? В отличие от установщикА, диспетчер пакета работает с хранилищами пакетов. Он знает, где лежат все пакеты, которые я могу захотеть установить. Хранилищ может быть несколько. Диспетчер кеширует индексы. Соответственно, есть две утилиты --- apt-get , который работает с хранилищами непосредственно, и apt-cache, котрый работает с кэшем. | ||
| + | Соответственно, диспетчер делает то, что не может установщик: строит дерево зависимостей, получает необходимые и запускает их установку. | ||
| + | * apt-get install <имя пакета> --- установка пакета | ||
| + | * apt-get remove <имя пакета> --- удаление пакета | ||
| + | * apt-get update --- обновление индексов | ||
| + | Таким образом, на долю утилиты apt ложится обновление из изменяющегося хранилища. | ||
| + | * apt-cache search --- ищет имтроку в именах пакетов, их описаниях и файлах | ||
| + | У обоих команд (rpm и apt) есть дикое количество ключей. | ||
| + | |||
| + | Кроме апта, есть есть графические утилиты для работы с пакетами. | ||
| + | |||
| + | Любая команда по работе с системой должна выполняться с правами суперпользвователя. | ||
| + | |||
| + | Ровно одна задача --- модификация самой системы --- делается с правами суперпользователя. | ||
| + | |||
| + | === Виды программ === | ||
| + | (отсортировано по вероятности того, что программа заработает в вашей системе) | ||
| + | * Бинарники — первый и самый наименее вероятный уровень. | ||
| + | ** Подвиндовз + wine | ||
| + | *** Wine имеет двух наследников — Wine intersoft и crossover office, небесплатных | ||
| + | ** Бинарники под Linux | ||
| + | *** Для того, чтобы такая программа нормально заработала нужно кроме программы предоставить все библиотеки, с которыми она собрана. Статическая сборка/с библиотеками | ||
| + | *** Если не статически собраны, то возникает проблема с версиями библиотек и размещением конфиг. файлов. | ||
| + | ** Практика показывает, что эта степень подлинуксовости — низшая | ||
| + | * Программа на Си++ | ||
| + | ** Тоже низшая степень подлинуксовости. Если я написал программу, она компилируется и работает, то я написал программу под Линукс. Такие проекты либо очень быстро задыхаются (ибо программа работает только на той машине, где писалась), либо очень простые | ||
| + | ** Сборка? Во многих случаях это возможно, но никакой гарантии нет | ||
| + | * Уровень крибле-крабле-бумс — использование Autotools | ||
| + | ** Способ делать более-менее кроссплатформенноен приложение. Они делают мейк-файл, который позволяет собирать программу на большом количестве систем. Вероятность сборки повышается, особенно если у вас просто линукс, а линукс это мейнстрим. | ||
| + | ** Кто и как часто собирает? Если нужно установить программу на нескольких машинах то что, надо всё время скачивать и пересобирать? Сборка это невоспроизводимый процесс (на разных машинах — разные программы) | ||
| + | * Пакеты другого дистрибутива (чужой пакет). Есть некоторая вероятность, что он не заработает. | ||
| + | ** Всё равно встаёт вопрос соместимости по библиотекам | ||
| + | ** Поскольку пакет не вашего дистрибутива, то он не входит в структуру. Вы обновляете дистрибутив, а пакет не обновляется. Дело в том, что когда вы дообновляетесь до того, что обновятся библиотеки так, что пакет перестанет работать, то надо что-то делать. | ||
| + | * spec-файл (для rpm). Можжно взять src.rpm и spec-файл, то можно попытаться собрать его, подсунув свои библиотеки. | ||
| + | ** Опять попадаете в ситуацию сизифового труда. Взяли спек, подправили баги, собрали, всё это в одиночку. Послезавтра если это надо будет установить на другой машине, то собирать придётся с начала. | ||
| + | ** Это не пакет. Он не обновляется, и т. д. | ||
| + | ** Можно доработать его до пакета, положить в дистрибутиьв и стать maintainerом этого пакета. | ||
| + | * Пакет дистрибутива. | ||
| + | |||
| + | Один забавный факт. Человек, от линукса далёкий, будет искать сверху вниз. Человек недалёкий будет делать это в обратном порядке. | ||
| + | |||
| + | В последнем случае получаются много бонусов. | ||
| + | |||
| + | Ровно до момента "чужой пакет" вы не являетесь членом сообщества вообще. И только в последнем случае вы — полноправный член сообщества. Единственное, чем этот путь плох — этот путь не для простого пользователя, это путь для разработчика. | ||
| + | |||
| + | Джава — ОС в ОС. Со стороны maintainerов дистрибутива, нужно положить в дистрибутив Джава-машину, эклипс и всё. (...) | ||
| + | |||
| + | === Как искать программы под Linux === | ||
| + | * Искать в дистрибутиве (apt-cache search). | ||
| + | ** Поиск в собственном дистрибутиве | ||
| + | ** Поиск в бэкпортах — сборка новых программ под старые дистрибутивы (окружения) | ||
| + | ** Поиск в тестовой версии | ||
| + | * Искать в чужом дистрибутиве. | ||
| + | ** Вероятность довольно высокая потому, что много людей пытались собрать эту программ до вас | ||
| + | ** src.rpm | ||
| + | ** rpm | ||
| + | * Поиск по разработчикам (sourceforge, savanna, freshmeat). Они выдадут по ключевым словам, какие существуют программные продукты, соотвествующие ключевым словам. Из этого списка нужно выбрать несколько кандидатов, посмотреть их, понять, почему до вас не собрали, собрать... | ||
| + | ** Это может не помочь по двум причинам | ||
| + | **# Не все проекты, особенно проекты экзотические (академические) попадают на эти порталы. Но елси у людей есть сайт, то крупные поисковые системы наверняка их проиндексировали по тем же ключевым словам (go google) | ||
| + | * Если всё это проделали, и результатов нет, то не значит, что софта не существует. Очень хороший источник информации — сообщество. | ||
| + | ** Поиск сообщества | ||
| + | ** Поиск ресурса в сообществе | ||
| + | ** Официальные информационные ресурсы (документация, сайт, wiki) | ||
| + | *** Списки рассылки | ||
| + | *** IRC, форумы (если игнор-лист правильно настроить) | ||
| + | |||
| + | === Спепцифика установки ПО из различных источников === | ||
| - | === Установка ПО из своего дистрибутива === | + | ==== Установка ПО из своего дистрибутива ==== |
В рамках дистрибутива всё будет хорошо. | В рамках дистрибутива всё будет хорошо. | ||
| - | === Установка ПО не из своего дистрибутива === | + | ==== Установка ПО не из своего дистрибутива ==== |
| - | ==== Установка из хранилища ==== | + | ===== Установка из хранилища ===== |
Когда вы обращаетесь к хранилищу, может случиться, что появились версии программ и все поменялось. В этом случае применим следующий способ: помимо rpm есть src.rpm, в котором содержится всё необходимое для сборки программного продукта. Можно скачать src.rpm и пересобрать его в своём окружении. Всё сводится к выполнению новых команд: | Когда вы обращаетесь к хранилищу, может случиться, что появились версии программ и все поменялось. В этом случае применим следующий способ: помимо rpm есть src.rpm, в котором содержится всё необходимое для сборки программного продукта. Можно скачать src.rpm и пересобрать его в своём окружении. Всё сводится к выполнению новых команд: | ||
| Строка 136: | Строка 234: | ||
* У нового бинарного rpm не будет проблем с зависимостями | * У нового бинарного rpm не будет проблем с зависимостями | ||
| - | ==== Установка из другого репозитория ==== | + | ===== Установка из другого репозитория ===== |
Проблема с чужим репозиторием может заключаться в том, что разделяемые библиотеки могут находиться в пакетах с другими именами. | Проблема с чужим репозиторием может заключаться в том, что разделяемые библиотеки могут находиться в пакетах с другими именами. | ||
| Строка 142: | Строка 240: | ||
Кроме того, пакеты из чужих репозиториев не обновляются/*автоматически?ручками то можно*/, что с определённого момента не позволит обновлять зависимые библиотеки, а также пакеты, которые зависят от этих библиотек. | Кроме того, пакеты из чужих репозиториев не обновляются/*автоматически?ручками то можно*/, что с определённого момента не позволит обновлять зависимые библиотеки, а также пакеты, которые зависят от этих библиотек. | ||
| - | ==== Сборка из исходных кодов ==== | + | ===== Сборка из исходных кодов ===== |
Существует два основных способа: сборка с использованием вручную написанного makefile и сборка с использованием autotools. Основная проблема в том, что если активно пользоваться программой, то при каждой новой версии выполняется последовательность команд configure, make, make install, в результате чего возникает большое количество версий одних и тех же библиотек, удалить которые нельзя, так как их может использовать кто-то ещё. Кроме того, может получиться, что старые библиотеки используются вместо новых. | Существует два основных способа: сборка с использованием вручную написанного makefile и сборка с использованием autotools. Основная проблема в том, что если активно пользоваться программой, то при каждой новой версии выполняется последовательность команд configure, make, make install, в результате чего возникает большое количество версий одних и тех же библиотек, удалить которые нельзя, так как их может использовать кто-то ещё. Кроме того, может получиться, что старые библиотеки используются вместо новых. | ||
| - | ==== Установка бинарника ==== | + | ===== Установка бинарника ===== |
Одна из проблем с бинарными файлами заключается в том, что они могут использовать свои библиотеки определённой версии, что никак не контролируется в рамках репозитория. Выходов два: сборки под разные дистрибутивы средствами разработчика или статическая сборка всех используемых библиотек. Стоит отметить, что в последнем случае гораздо больше вероятность, что запустится бинарник, чем пакет из другого дистрибутива. | Одна из проблем с бинарными файлами заключается в том, что они могут использовать свои библиотеки определённой версии, что никак не контролируется в рамках репозитория. Выходов два: сборки под разные дистрибутивы средствами разработчика или статическая сборка всех используемых библиотек. Стоит отметить, что в последнем случае гораздо больше вероятность, что запустится бинарник, чем пакет из другого дистрибутива. | ||
| Строка 156: | Строка 254: | ||
И то, и другое должно происходить от имени суперпользователя, что потенциально порождает проблемы (как и в любом другом случае установки ПО, но данный усугубляеется тем, что нельзя проконтролировать процесс). Как альтернатива, существуют директории ~/bin и ~/.local, в которые можно произвести инсталляцию, не имея прав root'а, но отнюдь не всегда эти пути прописаны в PATH./*мб все таки пояснить что такое PATH и почему там все должны быть прописаны? сноской.*/ | И то, и другое должно происходить от имени суперпользователя, что потенциально порождает проблемы (как и в любом другом случае установки ПО, но данный усугубляеется тем, что нельзя проконтролировать процесс). Как альтернатива, существуют директории ~/bin и ~/.local, в которые можно произвести инсталляцию, не имея прав root'а, но отнюдь не всегда эти пути прописаны в PATH./*мб все таки пояснить что такое PATH и почему там все должны быть прописаны? сноской.*/ | ||
| - | ==== Резюме ==== | + | ===== Резюме ===== |
По возможности (в частности, в случае использования пакетов из других хранилищ или сборки из исходных текстов) надо собирать пакеты и добавлять их в используемый репозиторий. Это позволит избежать проблем, связанных с зависимостями и обновлениями./*Резюме скорее для разработчиков, а не для детей. */ | По возможности (в частности, в случае использования пакетов из других хранилищ или сборки из исходных текстов) надо собирать пакеты и добавлять их в используемый репозиторий. Это позволит избежать проблем, связанных с зависимостями и обновлениями./*Резюме скорее для разработчиков, а не для детей. */ | ||
| Строка 191: | Строка 289: | ||
== Где искать ответы на вопросы == | == Где искать ответы на вопросы == | ||
| + | ... | ||
| + | |||
| + | == Ссылки == | ||
| + | * [[Спецкурс по Linux, весна 2007, 03 лекция (от 09 марта)|Виды ПО пд Linux]] | ||
| + | * [[UNИX, осень 2007, 09 лекция (от 30 ноября)|Пакет]] | ||
| + | * [[UNИX, осень 2007, 10 лекция (от 07 декабря)|Установщик, каталоги, настройка]] | ||
* [[UNИX, осень 2007, 11 лекция (от 14 декабря)|Лекция про информационный поиск]] | * [[UNИX, осень 2007, 11 лекция (от 14 декабря)|Лекция про информационный поиск]] | ||
| + | * [[UNИX, весна 2008, 13 лекция (от 07 мая)|Лекция про структуру дистрибутива и пакеты]] | ||
| + | * [[UNИX, весна 2008, 14 лекция (от 14 мая)|Лекция про установщик и менеджер пакетов]] | ||
| + | |||
| + | == Примечания == | ||
| + | <references /> | ||
Версия 10:31, 25 августа 2008
Содержание |
Установка и настройка ПО
Поиск ПО: где брать?
Одной из насущных проблем сразу после установки операционной системы является установка и настройка ПО для решения конкретных задач. Возникает вопрос: какое ПО существует и откуда его брать? Самый простой (но и наименее информативный) ответ на этот вопрос дает команда apt-cache show *. Но это не единственный вариант. Подходить к поиску ПО (как и к любой другой задаче) можно по-разному. Рассмотрим некий виртуальный пример, который, тем не менее, довольно часто встречается в реальной жизни:
Приходит человек и говорит: «У меня вот Photoshop, а что у вас в Линуксе есть?». Ему, как правило, отвечают: «А у нас есть GIMP». После чего человек уходит, а через некоторое время возвращается и говорит, что в GIMP нет ничего из того, что ему надо. Это самый плохой подход — подход от названия.
Более сложный и обстоятельный способ — подход от инструмента. Он популярен у людей, которые в определённой мере ориентируются в предметной области. В данном примере, поскольку Photoshop — программа, связанная с графикой, можно рассмотреть инструменты, связанные с графикой. Выделяют два основных вида графики -- векторную и растровую. Векторная графика, в свою очередь, делится на плакатную, макетную и диаграммы. Для плакатной графики используются Inkskape, Xara Xtreeme, Kontour и ещё добрый десяток различных приложений. Про печатные макеты можно прочитать на Википедии, и, например, узнать, что программы на PostScript редактировать не надо (PostScript -- это язык. На нём даже вирус можно написать). Для работы с диаграммами есть Dia, Xfig, OpenOffice.org Draw. Что касается растровой графики, то есть программы для обработки фотографий — GIMP, Krita. Есть аналоги MS Paint — их бесконечно много, один хуже проще другого. Из них можно вспомнить Tux Paint, Kolourpaint. Также существуют пакетные преобразователи, позволяющие писать разнообразные скрипты, преобразующие картинки. Ярким примером подобного инструмента является ImageMagick. Можно вспомнить ещё про 3D-графику — Blender, POV-RAY. При таком подходе на пришедшего с вопросом человека в итоге сваливается 200 названий, человек уходит,а когда возвращается, говорит, что Linux ужасно крут, но не умеет делать то, что ему надо.
И, наконец, третий подход — это подход от задачи. Если расспросить человека о том, что ему нужно, возможно, окажется, что у него есть фотоаппарат и он хочет управлять каталогом фотографий, назначать им теги, убирать красные глаза, и так далее. В этом случае сразу появляется решение — DigiKam, и, возможно, ещё gfoto2, если у камеры специфический драйвер.
Таким образом, получаем три подхода:
- от названия
- от инструмента
- от задачи
Обычно пользуются первым, реже вторым. Но правильный — третий. Сначала необходимо определить круг решаемых задач. После определения круга задач возникает вопрос, где искать инструменты(то есть, программы) для их решения.
Откуда вообще берутся программы под Linux? Надо дать достаточно точный и полный ответ, ибо обычно ответ звучит как «лежат на диске» или «скачиваются из сети». Рассмотрим то, где на самом деле берут ПО для Linux.
Дистрибутив и репозиторий
Дистрибутив — скомпонованный и отлаженный набор подготовленных к использованию программ. Эти программы взяты из некоего большего, чем сам дистрибутив, хранилища. То есть, существует хранилище, где имеется большое количество ПО (на самом деле таких хранилищ, «репозиториев», несколько), и его часть используется для создания дистрибутива. В этом хранилище находятся одни из самых последних версий большого количества программ, и, если человек какую-то программу в нём не находит, он, при достаточной квалификации, может добавить недостающую программу (найденную другими путями, которые будут рассмотрены далее) в хранилище. При этом, поскольку полное тестирование всего добавляемого и обновляемого ПО не проводится, то возможна несовместимость между различными приложениями и невозможность использования отдельных программ на некоторых конфигурациях. Как следствие, комфортно использовать ПО из репозитория (а не из дистрибутива) можно только при достаточной квалификации.
Когда принимается решение о создании очередного дистрибутива, то создаётся замороженная копия репозитория, в которой обновления производятся только для исправления критических ошибок. Эта замороженная копия тестируется, отлаживается. В последствии на основании этой проверенной копии делается собственно дистрибутив. В результате, если ставить программу из дистрибутива, то, в идеале, ничего нештатного произойти не должно.
Другие варианты
Не исключена ситуация, при которой нужного приложения в используемом репозитории не оказывается. Так как хранилищ существует несколько, то при отсутствии искомой программы в том хранилище, на котором базируется используемый вами дистрибутив, можно попробовать поискать в других репозиториях. Где ещё можно попытаться найти интересующее ПО: существуют специализированные сайты, такие как SourceForge.net, где разработчикам предоставляются средства для ведения разработки, а пользователям — средства поиска по имеющимся проектам. Кроме этого, существуют независимые сайты разработчиков, где программы могут распространяться как в виде исходных текстов, так и в собранном виде.
Рецепт: как искать программы под Linux
В результате выстраивается некая схема поиска ПО:
- Искать в дистрибутиве
- Искать в репозитории
- Искать в чужом дистрибутиве.
- Поиск по специализированным сайтам (sourceforge, savannah (http://savannah.gnu.org/, http://savannah.nongnu.org/), freshmeat)
- Поиск в google на предмет сайта разработчика
- Если всё это проделали, и результатов нет, то не значит, что приложения не существует. Очень хороший источник информации — сообщество.
- Официальные информационные ресурсы (документация, сайт, wiki)
- Списки рассылки
- IRC, форумы
- Сообщество на последнем месте (несмотря на свою достаточно высокую эффективность) потому, что до этого на поиск тратятся только собственное время, а в сообществе тратят своё время другие люди.
Установка ПО
Установку программ в Linux лучше делать в рамках своего репозитория, но можно выделить ряд других способов установки ПО:
- Установка из чужого дистрибутива/репозитория
- Сборка из исходных кодов
- Бинарный инсталлятор
Перед тем, как подробно рассматривать каждую из указанных возможностей, определим ряд понятий, которые нам при этом потребуются.
FHS
В Linux существует строгая иерархия каталогов (File Hierachy System, FHS), которая описывает структуру каталогов и их семантику. Подробно FHS описан в учебнике Курячего Г. В. «Операционная система Linux». Так, в соответствии с FHS, существует 4 места для ПО, 2 каталога для разделяемых библиотек, 1 каталог для документации, и так далее. Каждая программа, состоящая из многих файлов, размещает их в соответствии с их предназначением в соответствующие каталоги в ФС.
Пример размещения некоторых типичных файлов абстрактной программы:
- /usr/bin/prog — исполняемый файл программы
- /usr/share/doc/prog/README — файл-описание программы
- /usr/share/man/1/prog.tgz — страница руководства по программе
И всё это входит в один программный продукт.
В Linux достаточно аккуратно проделано разделение прав доступа, и пользователь не имеет права доступа на запись к большей части файловой системы (за исключением своей домашней директории и /tmp/). Тем не менее, процессы, запущенные под суперпользователем игнорируют ограничения доступа. Поэтому установка ПО обычно делается под root'ом (поскольку при этом создаются файлы в каталогах, которые закрыты на запись для простых пользователей), и установку программ, кроме как в свой каталог, обычный пользователь, в отличие от root'а, осуществить не может.
Пакет
Одной из основополагающих единиц в процессе работы с хранилищем программного обеспечения является пакет.
Пакет — файл, содержащий всё необходимое для установки и удаления программного продукта.
То есть, для установки программного продукта достаточно установить пакет, и после этого он должен заработать. Для удаления программного продукта, соответственно, достаточно удалить пакет.
Рассмотрим подробно, что представляет собой пакет:
- Пакет — архив, содержащий файлы программного продукта. Причём, архив вполне известной структуры. Достаточно ли просто его разархивировать? Нет.
- Пакет обеспечивает регистрацию программного продукта в системе. Должен быть зарегистрирован список устанавливаемых файлов, а также некая метаинформация, такая как имя пакета, его версия, и так далее.
- Пакет обеспечивает первичную настройку программного продукта, то есть, запуск программы, специфичной для данного пакета — некоего установочного скрипта. Таких скриптов может быть несколько.
В связи с этим возникает ряд вопросов:
- Что делать, если одни пакеты зависят от других (например, один программный продукт и использует в своей работе другой)?
- Как разрешать конфликты, то есть, те случаи, когда при попытке установить файл из архива оказывается, что такой файл есть, и создан он не пользователем, а другим пакетом?
Зависимости
Перед рассмотрением проблемы зависимостей введём понятие разделяемой библиотеки.
Разделяемая библиотека — самостоятельный набор библиотек, используемый другими программными продуктами.
Преимущества использования разделяемых библиотек:
- При использовании библиотек программы занимают меньше места, так как экземпляр библиотеки один, а не отдельные экземпляры для каждого программного продукта, её использующего.
- Библиотека загружается в память один раз
- Для разделяемой библиотеки не нужно даже иметь место в swap — swap'ом этого файла будет файл на диске
- Если в библиотеке есть ошибка, то её быстро найдут, поскольку она используется во многих программах, и, как следствие, интенсивно тестируется
Но, при всех достоинствах разделяемых библиотек, появляется проблема -- задача разрешения зависимостей. Разделяемые библиотеки не входят в пакет. Каждая группа библиотек находится в отдельном пакете. Перед установкой программного продукта необходимо установить все библиотеки, которые им используются, то есть, удовлетворить его зависимости. Получается палка о двух концах: с одной стороны, использование разделяемых библиотек упрощает и ускоряет разработку; с другой стороны, усложняется порядок установки программ — необходимо скачать и установить в правильном порядке всё дерево (точнее, ациклический орграф) зависимостей. В большинстве дистрибутивов Linux для автоматизации удовлетворения зависимостей существуют две программы — установщик и менеджер пакетов, которые подробно рассмотрены далее.
Кроме этого существуют непрямые зависимости. Возможна ситуация, когда для работы вашего продукта другой программный продукт не является необходимым, но с ним связана некая некритичная функциональность. Например, для почтового веб-сервера не обязательно нужен почтовый сервер, поэтому установка почтового сервера не должна требоваться, но его можно оформить как рекомендованный пакет, поскольку первое без второго используется редко.
Конфликты
Иногда при установке очередного пакета может возникнуть так называемый конфликт.
Конфликт — ситуация, при которой файлы из разных пакетов должны иметь одинаковые абсолютные имена/*абсолютное имя – откуда термин?не лучше ли «полностью одинаковые имена и пути»*/.
Пример конфликта: пакеты с различными вариантами vi: vi, vim-minimal, mvi пытаются установить бинарный файл /usr/bin/vi.
Существует метод, позволяющий разрешать конфликты — альтернатива. Для каждого пакета выбираются свои уникальные имена (в данном примере — /usr/bin/vi.original, /usr/bin/vim, /usr/bin/mvi). Кроме этого, создаётся файл с конфликтным именем (/usr/bin/vi), но он является символической ссылкой на один из файлов, боровшихся за данное имя. То, куда будет указывать символическая ссылка, решается при помощи отдельного механизма(например назначением пакетам некоторых весов и ссылкой на файлы пакета с наибольшим весом).
Установщик пакетов
Как сказано выше, единицей ПО считается пакет. Пакет обладает массой свойств — это не только распаковка, но и регистрация в системе, запуск некоторых сценариев при установке/удалении. Работой с отдельным пакетом занимается установщик.
Установщик — утилита, которая позволяет управлять отдельным пакетом. Сюда входят установка и удаление, проверка пакета на различные свойства, просмотр различий в версиях пакета, проверка зависимостей, и так далее.
По историческим причинам, в список обязаннстей установщика пакетов входит также их сборка пакетов из их исходных версий. В исходную версию пакета (src package) входит вся инфрмация, необходимая для его сборки.
Важно отметить, что установщик пакетов работает только с отдельными файлами, а не с репозиторием. Этот факт подробнее будет рассмотрен далее.
На данный момент существует определённое количество форматов пакетов и утилит по работе с ними. Наиболее популярными являются два следующих формата:
* RPM, RedHat Package Manager. Изначально появился в дистрибутиве RedHat. На данный момент используется в большом колоичестве RedHat-based (и не только) дистрибутивов, в число которых (косвенно, посредством Mandrake Linux) входит и ALT Linux. Установщиком для данного формата пакетов является дноимённая утилита rpm[1]
