From mboxrd@z Thu Jan 1 00:00:00 1970 To: devel@linux.iplabs.ru Subject: Re: [devel] RPM: including additional docs Message-ID: <20001125144141.A1060@localhost.localdomain> Mail-Followup-To: mookid@sigent.ru, devel@linux.iplabs.ru References: <20001124010924.A1348@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from vanyaz@mccme.ru on Sat, Nov 25, 2000 at 01:04:49PM +0300 From: mookid@sigent.ru (Mikhail Zabaluev) 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 14:41:41 +0300 Date: Sat, 25 Nov 2000 14:41:41 +0300 Archived-At: List-Archive: List-Post: Hello Ivan, On Sat, Nov 25, 2000 at 13:04 +0300, Ivan Zakharyaschev wrote: > > Hello! > > On Fri, 24 Nov 2000, Mikhail Zabaluev wrote: > > > Для начала предложу выделить эту отдельную документацию в отдельный > > пакет > > - чтобы строить как noarch независимо от основного пакета, и, поскольку > > исходные файлы распространяются отдельно, иметь меньше проблем с > > версиями > > и релизами. Я сделал так с php-manual и нисколько не жалею. > > В этом случае получилось. Но можно придумать иакую ситуацию, где: > > 1. нужно в главный пакет включить дополнительную документацию, которая не > из исходников программы (например, README.ipl). > > 2. Что-то из документационных файлов, входящих в состав распространяемых > исходников, хочется исклюить из основного пакета и включить во > вспомогательный doc. Тогда придется собирать все в один присест и с одной архитектурой. Как объяснил JBJ, архитектура влияет на процесс сборки, который в вышеописанных случаях нельзя проводить отдельно для подпакетов. Если крайне нужен отдельный noarch-подпакет (а на самом деле это лишь дань эстетике, за исключением разве что случая дистрибутива, содержащего, скажем, i586 и i686 "в одном флаконе" для всех пакетов - там действительно хорошо выделить весь noarch и не дублировать его), можно продублировать исходники или их часть в отдельном .src.rpm. Как хороший пример такого рода могу привести apache и mod_ssl. Из исходников mod_ssl выделены патчи и файлы, которые нужно приложить к Apache, и добавлены к пакету apache. mod_ssl собирается при установленных apache и apache-devel, с учетом того, что патчи приложены. Насчет того, куда класть дополнительные файлы. Прямо в корень дерева, где производится сборка, если они там не мешают. Вариант - создать подкаталог. Для %doc указать их местонахождение относительно корня сборки. Чего же тут сложного? > Эти два случая показывают, что нет полного соответсвия между получающимися > (под-)пакетами и разными группами исходников (я их называл модулями). > Из-за этого перекрещивания их нужно собирать за один заход, в рамках > одного spec-файла. > > > А касательно файлов, на мой взгляд, техника проста: размещаем их в том > > виде, в котором они попадут в %_docdir (т.е. архивы распаковываем, > > другие > > файлы - копируем), там, где rpm их будет искать по умолчанию - > > в $RPM_BUILD_DIR/%{name}-%{version}. Ну или сами укажите где, с помощью > > %setup -T -n <имя> > > Секции %build и %install можно опустить. Затем перечисляем в %files с > > директивой %doc - и файлы попадают куда надо. > > Ну да -- это все удобно в отдельном пакете. И, по-моему, такой способ как > раз является правильным с точки зрения концепций RPM. Что > именно тут удобно? То, что документация готовится к установке в отдельном > файловом пространстве ($RPM_BUILD_DIR). Почему в отдельном? Лежит она там вместе с остальными исходниками. > Остальые свойства такой сборки не > так уж важны: то, что создается отдельгый пакет. Как я уже сказал, может > быть нужно распределить эту документацию по разным пакетам. Так вот: чтобы > это удобное свойство подготовки документации в отдельном файловом > пространстве, присущее сборке отдельного пакета, совместить с возможностью > перераспределения документации по подпакетам, я предлагаю в > одном spec-файле использовать параллельные процедуры подготовки/сборки для > независимых модулей исходников. Результаты этих параллельных процедур > потом объединялись бы на стадии %install в единое дерево. Множественные стадии %build - это, конечно, заманчиво, но это серъезная модификация, а мы должны равняться на флагмана в море RPM - на RedHat (кроме того, что у нас просто нет ресурсов делать такие вещи). Макросы определять - еще куда ни шло, но серъезно нарушать совместимость не стоит. -- Stay tuned, MhZ mailto:mookid@sigent.ru ----------- When I'm good, I'm great; but when I'm bad, I'm better. -- Mae West _______________________________________________ Devel mailing list Devel@linux.iplabs.ru http://www.logic.ru/mailman/listinfo/devel