3.1.1. Основные понятие о пакетах

3.1.1. Основные понятие о пакетах

Давайте сначала рассмотрим процесс установки программ в Windows. Как правило, дистрибутив Windows-программы состоит та установочного файла (обычно называется setup.exe или install.exe) и нескольких вспомогательных файлов (например, архива, содержащего саму программу) или только из одного установочного файла (если последний выполнен по принципу самораспаковывающегося архива).

Установочный файл (далее инсталлятор) просит пользователя точнить параметры установки, например, выбрать каталог для установки, указать программную группу и т.д. Затем начинается установка программы: инсталлятор копирует файлы из дистрибутива программы в выбранный пользователем каталог. После этого инсталлятор вносит необходимые изменения в системный реестр. Все, программа установлена.

В Linux же все происходит несколько иначе. Дистрибутив программы (сама программа и вспомогательные файлы, напри-тер, файлы справки, конфигурационные файлы) поставляется в виде пакета. В мире Linux существуют два основных типа пакета: RPM-пакеты и DEB-пакеты. Первые пакеты используются во всех дистрибутивах, которые были основаны на Red Hat Linux или на производных этого дистрибутива: Fedora, ASP Linux, ALT Linux, Mandriva и т.д. DEB-пакеты используются дистрибутивом Debian и его производными (Ubuntu, Kubuntu и др.).

По сути, пакет (как RPM, так и DEB) - это архив, содержащий программу. Но кроме самой программы в этом архиве есть указания для менеджера пакетов о том, как нужно устанавливать программу. А именно: куда нужно установить тот или иной файл программы, какие команды нужно выполнить до и после установки и т.д.

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

В Windows к идее пакетов (файлы с расширением .msi) пришли позже, но она не получила широкого распространения. Фактически в MSI-пакетах распространяются только программы от Microsoft, а сам процесс установки пакета напоминает работу обычного инсталлятора.

Но вернемся к RPM-пакетам. Как уже говорилось, в пакете содержать служебные инструкции для менеджера пакетов о том, куда установить тот или иной файл, а также о командах, которые нужно выполнить в процессе установки пакета. Кроме этил сведений, в пакете содержатся также сведения о зависимости, т.е. список пакетов, от которых зависит данный пакет, и список пакетов, с которыми устанавливаемый пакет конфликтует,

Тут псе просто. Предположим, что у нас есть библиотека, с использованием функций. которой написана программа, например, Qt. Если библиотека не установлена на компьютере, то и программа работать не будет. Но библиотека занимает много места, поэтому вместе с программой ее распространять не будешь (тем более, что библиотека-то стандартная и входит в состав многих дистрибутивов). Разработчику программы намного проще при сборке пакета указать, что пакет требует наличия библиотеки Qt. Менеджер пакетов видит эту зависимость, и если она не удовлетворена, пытается ее разрешить, другими словами, скачать пакет с Интернета (или другого хранилища макетов). В ранних версиях Linux менеджеры пакетов не умели разрешать такого рода зависимости: вы просто получали сообщение о том, что пакет установить невозможно по причине отсутствия такого-то пакета.

Теперь договорим о конфликтах. Предположим, что вы написали свой собственный WWW-сервер, ваш коллега тоже написал программу WWW-сервер. Как мы знаем, WWW-сервер использует для своей работы порт 80. Пользователь установил на свой компьютер ваш WWW-сервер, который сразу же после своего запуска узурпировал 80-й порт. При попытке установить на этот же компьютер второй WWW-сервер пользователь получит сообщение о том, что устанавливаемый пакет конфликтует с уже установленным (причина конфликта ясна: в системе может быть только одна программа, использующая 80-й порт). Конечно, такое сообщение пользователь увидит лишь в той случае, если разработчик второго сервера (или вы – для своего пакета – разницы нет) не поленится составить список конфликтов. Если же он поленился это сделать, то последствия такой установки ни к чему хорошему не приведут – скорее всего, оба WWW-сервера работать не будут,

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