From: Aleksey Avdeev <solo@solin.spb.ru> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] Рано поднимать до error Date: Sun, 27 Jan 2013 00:38:31 +0400 Message-ID: <51043EC7.5020007@solin.spb.ru> (raw) In-Reply-To: <20130126190710.GD6704@atlas.home> [-- Attachment #1: Type: text/plain, Size: 5764 bytes --] 26.01.2013 23:07, Sergey Vlasov пишет: > On Sat, Jan 26, 2013 at 09:36:17PM +0400, Aleksey Avdeev wrote: > [...] >> Если дело в сокращении set-versions (через замену их на строгие >> зависимости), так может и ограничиться ими (простановкой строгих >> зависимостей вместо внутрипакетных set-versions) и не стоит остальное с >> плеча рубить? >> >> Как на счёт варианта: >> >> 1. Проставлять строгие зависимости вместо нестрогих с внутрипакетными >> set-versions, без возможности отключения данного механизма. >> >> 2. Во всех остальных случаях, по умолчанию менять внутрипакетные >> нестрогие зависимости на строгие, предусмотреть ручку для отключения >> таких замен. > > В соседней ветке предложен похожий вариант: > > http://lists.altlinux.org/pipermail/devel/2013-January/196540.html > > | Другими словами, предлагается модифицировать алгоритм, чтобы он работал > | следующим образом: подпакет A исходного пакета S автоматически получает > | строгую зависимость от подпакета B исходного пакета S, если выполнено любое > | из следующих условий: > | - у A есть зависимость от B; > | - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B > | является единственным подпакетом S, удовлетворяющим эту зависимость X. > > Можно переформулировать это описание таким образом: > > 1. Зависимости, найденные через find-requires (это могут быть не > только set-versions, а и, например, perl(foo.pm)), которые > удовлетворяются ровно одним подпакетом собираемого пакета, > заменяются на строгие зависимости на этот подпакет без возможности > отключения. Для меня допустимо, если явно указанные файловые зависимости ("Requires: <file>" при наличии "Provides: <file>" в соответствующем подпакете) под этот пункт не попадают. > > (Интересно, встречаются ли реально ситуации, когда зависимость, > найденная find-requires, удовлетворяется более чем одним > подпакетом.) > > 2. Зависимости, явно указанные в Requires, в которых указано реальное > имя подпакета, заменяются на строгие зависимости на этот подпакет > также без возможности отключения. > > (Теоретически возможна ситуация, когда имя реального подпакета > присутствует также в другом подпакете в Provides - не уверен, что > такое стоит вообще допускать; в этом случае, согласно приведённому > алгоритму, зависимость не будет заменяться на строгую.) > > 3. Зависимости, явно указанные в Requires, но с именем, не > совпадающим ни с одним реальным именем подпакета, оставляются без > изменения, даже если эта зависимость удовлетворяется ровно одним > подпакетом. > > Это правило позволяет не сломать пакеты типа xboard, в которых > присутствует подпакет, допускающий замену на альтернативные > варианты (в случае xboard в том же пакете собирается подпакет с > темой по умолчанию, но вместо него может быть установлен любой > другой пакет с темой, при этом минимум одна тема должна > присутствовать). Аналогичная ситуация и в пакете osec (с той лишь > разницей, что в данный момент в Сизифе нет ни одного пакета, > которым можно было бы заменить osec-mailreport, но указанные в > osec-cronjob зависимости позволяют создать такой альтернативный > пакет). > > Также под этот пункт могут попасть ошибочно оставленные > зависимости на устаревшее имя подпакета, если производилось > переименование подпакета с проставлением соответствующих Provides > и Obsoletes, но такую ситуацию можно обнаружить по наличию > Obsoletes с этим именем (если же ещё и Obsoletes забыли, тут уже > ничего не поможет, одна надежда на багрепорты по поводу > неработающего обновления). > > При использовании этих правил, если требуется обеспечить нестрогую > зависимость между подпакетами, собираемыми из одного исходного пакета, > такую зависимость нужно будет реализовывать через промежуточный > виртуальный пакет (при этом могут быть наложены ограничения на версию > этого виртуального пакета, отражающие особенности собираемого ПО - > например, можно требовать совпадения major-версии или какого-то > внутреннего номера версии API). > > Кстати, при анализе этих правил возник ещё один вопрос - что делать с > зависимостями, более сложными, чем "Requires: B" без указания версии, > в которых, тем не менее, указано реальное имя подпакета? Например, > если указано "Requires: B = %version" (без "-%release"), нужно ли > менять эту зависимость на строгую? А ведь возможен ещё вариант вида > "Requires: B >= x.y", для которого автоматическая замена на строгую > зависимость выглядит ещё более сомнительно (ведь зачем-то эта > нестрогая зависимость была записана именно в таком виде). Возможно, > зависимости с условием, отличающимся от "=", также стоит оставлять в > неизменном виде, что также даст возможность создания ограниченно > нестрогих зависимостей - например, в пакете версии x.y.z может быть > указано "Requires: B >= x.y" и "Conflicts: B >= x.(y+1)". У меня в качестве типовых нестрогих внутрипакетных зависимостей как правило используются: "Requires: B >= x.y", "Conflicts: С <= x.y" (где B и C как реальные так и виртуальные подпакеты) и "Requires: <file>" (как правило при этом есть подпекет предоставляющий соответствующий "Provides: <file>"). Принудительная замена такого рода внутрипакетных зависимостей, без возможностей её отключения -- большая засада, для меня... PS: Пересборка apache2-2.2.22-alt15 средствами librpmbuild-4.0.4-alt100.63 (на people) показала что не так страшен чёрт, как его малюют: результат вполне приемлемый, на первый взгляд. (Более детально разбтраться в понедельник буду.) -- С уважением. Алексей. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 900 bytes --]
next prev parent reply other threads:[~2013-01-26 20:38 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-03 16:40 [devel] samba Led 2013-01-03 22:36 ` Alexey Shabalin 2013-01-03 22:45 ` Led 2013-01-04 9:55 ` Alexey Shabalin 2013-01-23 20:14 ` [devel] non-strict dependency warnings Dmitry V. Levin 2013-01-23 21:05 ` Igor Vlasenko 2013-01-24 6:44 ` Dmitry V. Levin 2013-01-24 10:47 ` Aleksey Avdeev 2013-01-24 11:25 ` Dmitry V. Levin 2013-01-24 17:58 ` [devel] non-strict dependency in apache2 (was: non-strict dependency warnings) Aleksey Avdeev 2013-01-24 19:15 ` Dmitry V. Levin 2013-01-24 23:19 ` [devel] non-strict dependency in apache2 Aleksey Avdeev 2013-01-24 23:37 ` Dmitry V. Levin 2013-01-25 0:48 ` Aleksey Avdeev 2013-01-25 8:53 ` Dmitry V. Levin 2013-01-25 10:11 ` Aleksey Avdeev 2013-01-26 9:22 ` [devel] %_allowed_nonstrict_interdeps (was: non-strict dependency warnings) Aleksey Avdeev 2013-01-24 6:46 ` [devel] non-strict dependency warnings Dmitry V. Levin 2013-01-24 11:21 ` Dmitry V. Levin 2013-01-24 16:00 ` Dmitry V. Levin 2013-01-24 16:22 ` Led 2013-01-24 22:16 ` [devel] %EVR macro Dmitry V. Levin 2013-01-24 22:37 ` Led 2013-01-24 23:21 ` Aleksey Avdeev 2013-01-24 12:07 ` [devel] non-strict dependency warnings Igor Vlasenko 2013-01-24 6:53 ` [devel] dependency needs Epoch warnings Dmitry V. Levin 2013-01-24 7:09 ` Yuri N. Sedunov 2013-01-24 7:16 ` Dmitry V. Levin 2013-01-24 7:24 ` Yuri N. Sedunov 2013-01-24 10:25 ` Aleksey Avdeev 2013-01-24 11:31 ` Dmitry V. Levin 2013-01-24 12:21 ` Aleksey Avdeev 2013-01-24 16:52 ` Dmitry V. Levin 2013-01-24 21:44 ` [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common} (was: dependency needs Epoch warnings) Aleksey Avdeev 2013-01-24 21:47 ` Dmitry V. Levin 2013-01-24 22:26 ` [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common} Aleksey Avdeev 2013-01-24 21:53 ` [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common} (was: dependency needs Epoch warnings) Dmitry V. Levin 2013-01-24 22:31 ` [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common} Aleksey Avdeev 2013-01-24 12:15 ` [devel] dependency needs Epoch warnings Igor Vlasenko 2013-01-23 22:29 ` [devel] non-strict dependency warnings Led 2013-01-23 22:37 ` Dmitry V. Levin 2013-01-23 22:43 ` Led 2013-01-24 11:57 ` [devel] Рано поднимать до error (was: non-strict dependency warnings) Sergey V Turchin 2013-01-24 12:23 ` [devel] Рано поднимать до error Aleksey Avdeev 2013-01-24 12:31 ` [devel] non-strict dependency warnings Dmitry V. Levin 2013-01-24 12:55 ` Sergey V Turchin 2013-01-24 14:49 ` Dmitry V. Levin 2013-01-24 14:59 ` Sergey V Turchin 2013-01-26 8:49 ` [devel] Рано поднимать до error REAL 2013-01-26 10:39 ` Dmitry V. Levin 2013-01-26 17:36 ` Aleksey Avdeev 2013-01-26 19:07 ` Sergey Vlasov 2013-01-26 20:08 ` [devel] non-strict deps Dmitry V. Levin 2013-01-26 20:39 ` Dmitry V. Levin 2013-01-26 23:31 ` Igor Zubkov 2013-01-26 23:56 ` Dmitry V. Levin 2013-01-27 0:25 ` Led 2013-01-27 0:37 ` [devel] gear-rules Dmitry V. Levin 2013-01-27 0:56 ` Led 2013-01-27 1:01 ` Dmitry V. Levin 2013-01-27 1:09 ` Led 2013-01-30 0:50 ` [devel] non-strict deps Igor Zubkov 2013-01-30 0:55 ` Dmitry V. Levin 2013-01-26 20:38 ` Aleksey Avdeev [this message] 2013-01-27 7:00 ` [devel] Рано поднимать до error Sergey Vlasov 2013-01-04 1:58 ` [devel] samba REAL 2013-01-04 11:06 ` [devel] llvm Dmitry V. Levin 2013-01-04 15:32 ` REAL 2013-01-04 15:24 ` Valery V. Inozemtsev 2013-01-05 5:13 ` REAL 2013-01-05 9:43 ` Dmitry V. Levin
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=51043EC7.5020007@solin.spb.ru \ --to=solo@solin.spb.ru \ --cc=devel@lists.altlinux.org \ /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