From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Zakharyaschev To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT Subject: [devel] RPM: build procedure Sender: devel-admin@linux.iplabs.ru Errors-To: devel-admin@linux.iplabs.ru X-BeenThere: devel@linux.iplabs.ru X-Mailman-Version: 2.0beta6 Precedence: bulk Reply-To: devel@linux.iplabs.ru List-Help: List-Post: List-Subscribe: , List-Id: IPLabs Linux Team Developers mailing list List-Unsubscribe: , List-Archive: http://www.logic.ru/pipermail/devel/ X-Original-Date: Sat, 25 Nov 2000 13:04:14 +0300 (MSK) Date: Sat, 25 Nov 2000 13:04:14 +0300 (MSK) Archived-At: List-Archive: List-Post: Добрый день! Хоть и комментарии по поводу разных 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