[devel] RPM: build procedure

[Ivan Zakharyaschev <vanyaz@mccme.ru>]

	Добрый день!

Хоть и комментарии по поводу разных targets для подпакетов уже были, я
расскажу более подробно о своем видении проблемы.

Возможность создавать некоторые подпакеты из общего spec-файла без
предназначения для определенной платформы я бы представил в spec-файле
тэгом ForceTarget: noarch, включаемым в заголовок подпакета. Это
заставляло бы RPM помечать этот пакет как noarch независимо от того, для
какой общей target происходит сборка. Обеспечение того, что в этот пакет
не попадает платформозависимых файлов, лежало бы на совести packager'а
(ему могли бы помогать какие-нибудь утилиты, анализирующие состав
подпакета).

От ExclusiveArch этот тэг принципиально отличался бы вот в чем:

- ExclusiveArch стремится главным образом определить архитектуру машины,
на которой может собираться пакет, а не target (устанавливаться);

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

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


Идея же, высказанная в том письме, о создании для каждой архитектуры своей
процедуры сборки со своей независимой стадией %build мне кажется не очень
удачной (неудобно, когда раздел %build длинный).

Я же что-то похожее предлагал в письме про дополнительную документацию.
Там я писал о независимых стадиях %prepdoc, %builddoc и %installdoc,
работающих в своем файловом пространстве. Почему такое нужно/возможно?
Потому что обработка дополнительной документации совершенно независима от
компиляции программы -- нужны только их результаты, соединенные в едином
дереве $RPM_BUILD_ROOT, эмулирующем target-систему.

Можно этот подход обобщить: выделять среди исходных данных модули, внутри
состоящие из зависимых друг от друга элементов, а между собой не
связанные.  Каждый такой модуль проходит свою обработку: распаковывается
(%prep), перерабатывается (%build) в своем файловом пространстве. Эти
действия с каждым из модулей могут происходить независимо от других, т.е.
параллельно им (необязательно во времени). Потом результаты переработки
этих модулей нам все-таки нужны вместе -- иначе какой смысл объединять их
в один пакет?  И для этого у каждого модуля есть своя процедура %install:
она из своего файлового пространства устанавливает результаты сборки в
единое дерево.  После этого про модули можно забыть. Теперь другое
разбиение получившейся системы: на подпакеты, т.е. на группы элементов,
объединенных по сфере применения и независимых во время
выполнения/использования.  (Модули были независимы во время сборки.)

Таким образом spec-файл разбивается на две части: то, что перед %install,
и то, что после. Сама стадия %install (на самом деле их много у каждого
модуля) связывает эти две части: с одной стороны, она объединяет
результаты бывших до этого момента независимыми модулей, а с другой
стороны, предоставляет единую систему для последующего переразбиения на
подпакеты.

Такое разделение spec-файла на две части может быть обосновано: пакет --
посредник между пользователем (его ОС) и исходным кодом программы (ее
создателем). Т.е. с одной стороны, RPM должна понимать нужды пользователя,
структуру его системы, предосталять ему возможность строить свою систему в
соответсвии с потребностями. Для этого нужны (под)пакеты -- единицы
структуры для пользователя. С другой стороны, RPM должна понимать
создателя программы, то, как обращаться с его кодом, как его
компилировать, как извлечь из него что-то (максимум) полезного. И это
задача первой части сборки пакета, каждый модуль для особой части исходных
данных. И в каком-то месте эти две вещи (нацеленность на
пользователя и приспособленность к разработчику) должны стыковаться.
Прямого соответсвия между модулями и подпакетами быть не должно и не может
-- они сгруппированы по разным принципам. Способ оcуществить переход от
одних к другим -- свалить все в кучу на стадии install.

Пример, который я уже приводил: работа с дополнительной документацией.
Других реальных примеров возможного такого устройства процедуры сборки
пакета я не вижу.

-- 
Best regards,
      Ivan Z.


_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel