Хотя Linux, понимаемый как ядро операционной системы, великолепен, одного ядра недостаточно для выполнения даже рутинных задач. Точное техническое определение понятия "операционная система" - по сей день предмет жарких дебатов. Однако фактически любой пользователь Linux помимо ядра использует массу приложений (начиная от стандартной библиотеки C и заканчивая такими пафосными в мире Unix приложениями, как редактор vi) для достижения своих повседневных целей, поэтому мы понимаем Linux расширительно, как дистрибутив ОС, как GNU/Linux.

Пользователи используют Linux и в качестве платформы для запуска веб-сервера Apache, и в качестве десктопа для запуска OpenOffice.org, и в качестве пускача для Lotus Notes/Domino и других коммерческих приложений. Но в целом - в качестве хоста для множества функциональных пакетов ПО. По сути дела, пользователи перестали различать Linux как ядро и Linux как все остальное, что приходит в составе дистрибутива. Некоторые дистрибутивы поставляются в составе десятков тысяч пакетов (много DVD-дисков). Эта ситуация просто требует эффективной системы пакетного менеджмента. Плюс ко всему, свободное программное обеспечение поставляется в основном в виде исходных кодов и может быть установлено в систему только после сборки бинарных модулей.

Множество пользователей не имеют достаточной квалификации для решения многих задач разработчика, например, кросс-сборки целой системы из исходного кода. И даже если кто-то решил приобрести квалификацию по ходу процесса, чем окупится время, затраченное на разворачивание и компиляцию системы с нуля, если конечная цель - запустить на своей машине Linux?

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

Самые первые дистрибутивы, такие как MCC и SLS представляли собой ни что иное, как снимки с рабочих винчестеров разработчиков. Пользователь не имел никаких инструментов контроля за тем, что будет установлено в его системе, если он скопирует себе такой снапшот. Что было на текущий момент, то инсталлятор устанавливал и пользователю. Поэтому наилучшим выбором было собирать свой дистрибутив самому. Разработчики, однако, быстро смекнули, что популярность дистрибутива зависит от возможности выбора в широком смысле слова, как во время инсталляции, так и после установки системы. Начался поиск оптимальных решений.

Например, Slackware делил все приложения на несколько функциональных категорий. Все пользователи получали базовую систему. Если нужно было что-то еще, пользователь мог выбрать категорию. Нужны сетевые приложения - устанавливались все сетевые приложения. Нужна графика - устанавливался X-сервер и все графические приложения. Эта концепция реализовывала принцип свободы выбора, но на очень примитивном уровне.

Следующий логический шаг в эволюции дистрибутивов - разработка инструментов детального контроля устанавливаемых приложений. Несколько вендоров дистрибутивов занялись независимой разработкой средств управления ПО на уровне приложений. Было ясно, что Slackware двигается в правильном направлении, но атомизация процесса должна базироваться на отдельном приложении, чтобы его можно было установить/удалить.

В 1993 году Rik Faith, Doug Hoffman и Kevin Martin начали публиковать первые бета-версии дистрибутива BOGUS. BOGUS был снабжен системой пакетного менеджмента (pms) и базировался на концепции возможности установки/удаления ПО на уровне приложений. Некоторое время спустя был представлен коммерческий дистрибутив Red Hat Commercial Linux (лето 1994 года). Первоначально Red Hat использовал Software Program Packages (RPP) в качестве системного инструмента управления пакетами. Подобно pms, RPP здорово облегчал задачу установки/удаления ПО.

Хорошие идеи приходят в голову хорошим людям одновременно, поэтому тем же летом 1994 года Ian Murdock основал дистрибутив Debian Gnu/Linux, который в свою очередь базировался на системе управления пакетами dpkg, разрабатываемой с начала 1993.

Далее - Цели разработки RPM
Содержание