From: mookid@sigent.ru (Mikhail Zabaluev) To: devel@linux.iplabs.ru Subject: Re: [devel] RPM: including additional docs Date: Sat, 25 Nov 2000 14:41:41 +0300 Message-ID: <20001125144141.A1060@localhost.localdomain> (raw) In-Reply-To: <Pine.LNX.4.30L.0011251221040.902-100000@zephyrous.ru>; from vanyaz@mccme.ru on Sat, Nov 25, 2000 at 01:04:49PM +0300 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
next prev parent reply other threads:[~2000-11-25 11:41 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2000-11-23 18:46 Ivan Zakharyaschev 2000-11-23 22:09 ` Mikhail Zabaluev 2000-11-25 10:04 ` Ivan Zakharyaschev 2000-11-25 11:41 ` Mikhail Zabaluev [this message] 2000-11-25 21:03 ` Ivan Zakharyaschev
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20001125144141.A1060@localhost.localdomain \ --to=mookid@sigent.ru \ --cc=devel@linux.iplabs.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git