Перед тем, как начать собирать rpm-пакет, необходимо выполнить несколько шагов в духе генеральной линии. Для того, чтобы быть уверенным, что все действительно готово.

13.2.1.1 Создайте пакет с исходным кодом
Наличие пакета с исходным кодом позволяет превращать исходники в пакеты для любой системы, любой архитектуры с помощью инструкций, заложенных в spec-файл. Возникает два полезных эффекта - все время отслеживается эволюция ПО и можно в любой момент получить бинарный rpm, пересобрав src.rpm.

Иными словами, создайте поколения rpm-пакетов, следуя соглашениям системы RPM и превратите такой подход в обычный для вас путь разработки.

13.2.1.2 Начинайте с чистых исходников
Кроме планирования процесса сборки, следует помнить, что нужно начинать с чистых, неизмененных исходных текстов приложения, из которого формируется пакет. Старт с чистого листа означает, что можно воспроизвести все детали процесса эволюции ПО, вплоть до отката в самое начало, если это потребуется.

Для всех изменений кода используются патчи. Таким образом, все внесенные изменения у вас в руках.

Некоторые rpm-пакеты имеют сотню и более патчей, которые rpmbuild применяет к коду в процессе сборки. Несмотря на это, при добавлении новых патчей процесс никак не изменяется.

Сохранение патчей отдельно от изначального исходного кода делает несложной задачу отката к прежним состояниям и задачу интеграции в пакет новых версий ПО.

13.2.1.3 Решите, что именно содержится в каждом пакете
Нет никакой практической необходимости помещать все ваше ПО в один пакет. Вместо этого разработчики, как правило, стремятся поделить большие проекты на несколько пакетов, возможно зависимых друг от друга. Например, сама система RPM имеет один пакет для базовой системы, один для разработчиков RPM, rpm-devel, и один для ПО сборки пакетов, rpm-build. Также имеются средства интеграции, например прикладной программный интерфейс для Python в пакете rpm-python.

Почему такое разделение важно? Возьмем, например, rpm-python. Этот пакет зависит от самого Python. Зачем заставлять пакет системы RPM зависеть от Python? Разделение на более мелкие структурные единицы позволяет избегать подобных коллизий.

В процессе разделения ПО на пакеты следует держать в уме два соображения:

- мы делим ПО на пакеты, так как это адаптирует принятую модель к пользователю;
- мы делим ПО на пакеты, так как маленькие пакеты просты, а это облегчает их создание и сопровождение.

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

Если разделение пакета на более мелкие не упрощает вещи, а усложняет, значит в конкретном случае это была, возможно, нездоровая идея.

13.2.1.4 Создайте тестовую базу данных RPM
В процессе сборки пакетов RPM так или иначе обращается к БД RPM. Но вы не обязаны работать с общесистемной БД. Если имеется тестовая БД RPM, можно устанавливать и тестировать пакеты в рамках этой БД. Для осуществления такого подхода задействуйте опции --justdb, --dbpath, --prefix, и --badreloc . Эти опции позволяют установить пакеты только в БД, в альтернативную БД, в другой "корневой" каталог.

Опция --test позволяет понять, что происходит при установке, на самом деле не выполняя ее.

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

Можно также скопировать системную БД RPM в такую директорию и использовать ее. При этом пути к файлам в БД будут совпадать с реальными системными путями.

Независимо от того, как вы создаете тестовую БД, пересоздавайте базу всякий раз, когда выполняется тот или иной тест. Это необходимо для уверенности в том, что начальные условия нам известны, и они одинаковы. Обычно это сводится к копированию исходной тестовой БД в каталог, где происходят тесты.

Далее - Передовой опыт: сборка
Назад - Разомкните циклические зависимости
Содержание