Все ранние инструменты управления системными свойствами в конечном итоге имели одну цель. Они пытались предоставить возможности установки целого приложения с помощью одной команды, отслеживания файлов, которые должны быть установлены в систему и удаления этих файлов также с помощью одной команды. Поскольку этот подход предлагался в качестве преимущества, постольку он и был популярен. Все ранние системы, однако, имели как технические, так и практические недостатки. Некоторые работали только на 32-разрядной Intel-платформе, хотя наличие иных платформ и ядра для них требовали кроссплатформенных свойств от подобных приложений. Другие инструменты имели проблемы в процессах проверки подготовленных пакетов, что делало невозможной уверенность в правильности сборки пакетов и воспроизводимую сборку. Из-за этих нерешенных вопросов, после выхода первого релиза Red Hat Linux разработчики обратили пристальное внимание на собственную систему RPP и другие подобные системы, в частности на ПО BOGUS pms. Разработчики Red Hat Marc Ewing и Erik Troan принялись за написание того, что они назвали Red Hat Package Manager (RPM). Основываясь на подходах ранних систем управления, своих знаниях и сравнительном анализе, Red Hat имела в виду несколько ясных ориентиров при разработке RPM. Среди них были следующие функциональные требования:

* Легкость использования
* Ориентирование на понятие "пакет"
* Возможность обновления пакетов
* Отслеживание межпакетных зависимостей
* Возможность различных запросов
* Возможность верификации
* Поддержка различных процессорных архитектур
* Использование "чистых" исходников

В следующих главах показывается, как Red Hat удалось выполнить эти требования в проекте RPM.

Далее - Легкость использования
Назад - Необходимость системы пакетного менеджмента
Содержание