From: Ivan Zakharyaschev <vanyaz@mccme.ru> To: <devel@linux.iplabs.ru> Subject: Re: [devel] RPM: including additional docs Date: Sun, 26 Nov 2000 00:03:03 +0300 (MSK) Message-ID: <Pine.LNX.4.30L.0011252259050.1003-100000@zephyrous.ru> (raw) In-Reply-To: <20001125144141.A1060@localhost.localdomain> Hello! On Sat, 25 Nov 2000, Mikhail Zabaluev wrote: > Тогда придется собирать все в один присест и с одной архитектурой. Как > объяснил JBJ, архитектура влияет на процесс сборки, который в В общем случае влияет на процесс сборки. Мы же хотим научиться описывать разумные исключения. > вышеописанных случаях нельзя проводить отдельно для подпакетов. Если > крайне нужен отдельный noarch-подпакет (а на самом деле это лишь дань Если крайне нужен, то можно еще обмануть RPM (исползуя --short-cicuit с -bi и -bb с разными targets): но тогда будут проблемы с системами автоматической сборкм и с тем, чтобы объяснить другим, как получилось собрать такие пакеты. > эстетике, за исключением разве что случая дистрибутива, содержащего, > скажем, i586 и i686 "в одном флаконе" для всех пакетов - там > действительно > хорошо выделить весь noarch и не дублировать его), можно продублировать Можно использовать довольно грубый метод для избежания дублирования: сравнивать содержательную часть пакетов, построенных для разных targets, и если они не отличаются, то исключать один. (В основном все собирается для i586 и i686, поэтому вместо дублирующего пакета для i686 можно ставить ссылку на тот, который для i586: при таком способе выявления дубликатов нет гарантии того, что обнаружен настоящий noarch.) > Для %doc указать их местонахождение относительно корня сборки. Чего же > тут > сложного? Да ничего. Никаких серьезных практических проблем я не вижу. Как Вы сами сказали, все это эстетика. > > именно тут удобно? То, что документация готовится к установке в > отдельном > > файловом пространстве ($RPM_BUILD_DIR). > > Почему в отдельном? Лежит она там вместе с остальными исходниками. Может, "файловое пространтсво" мною неправильно употреблено. Я имел в виду самое обыкновенное свойство RPM: что сборка не поднимается выше BUILD/name-ver/ и никто другой туда не залезает, что обеспечивает независимость сборок разных пакетов. > Множественные стадии %build - это, конечно, заманчиво, но это серъезная > модификация, а мы должны равняться на флагмана в море RPM - на RedHat > (кроме того, что у нас просто нет ресурсов делать такие вещи). Макросы > определять - еще куда ни шло, но серъезно нарушать совместимость не > стоит. Я понимаю -- я просто высказываю свои мысли, это вовсе не руководоство к действию. Ваши слова заставили задуматься о совместимости, так вот: можно постараться и сделать так, чтобы никакой серьезной несовместимости при внесении таких возможностей в RPM не будет. Например, написано в spec-файле %build ... %builddoc ... Модифицированный RPM поймет это как две параллельные стадии build. А если нынешнему RPM определить %buildoc как пустой макрос, то он выполнит последовательно описанные действия, в результате чего будет собрана программа и документация. Если написавший это не полагался на то, что деревья сборки одного и другого разные (если нет одинаковых имен), то проблем не будет. Такую сборку ("старым" rpm собирать по spec-файлу для модифицированного) кто-то может захотеть провести только для получения пакета для личного пользования, и поэтому те проблемы удобства, которые стояли перед упаковщиком и которые решали модификации RPM, его волновать не будут: -- какие-то пакеты вместо noarch получатся его архитектуры, он их себе и установит (я говорю, суммируя все предложенные новые возможности); -- документация распакуется на стадии %prep -- ну и что, он ведь не будет вносить в нее изменения и много раз пересобирать пакет. А packager'ы могут пользоваться модифицированной версией для создания более приятного дистрибутива и удобства работы. -- Best regards, Ivan Z. _______________________________________________ Devel mailing list Devel@linux.iplabs.ru http://www.logic.ru/mailman/listinfo/devel
prev parent reply other threads:[~2000-11-25 21:03 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 2000-11-25 21:03 ` Ivan Zakharyaschev [this message]
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=Pine.LNX.4.30L.0011252259050.1003-100000@zephyrous.ru \ --to=vanyaz@mccme.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