From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Date: Fri, 5 Feb 2021 12:41:15 +0300 From: "Alexey V. Vissarionov" To: ALT Linux Team development discussions Message-ID: <20210205094115.GE2874@altlinux.org> References: <20210204154552.GA6158@altlinux.org> <20210204162109.GC1217@altlinux.org> <20210204171324.GA7523@altlinux.org> <20210204194550.GA2874@altlinux.org> <20210204210113.GC2874@altlinux.org> <20210205024541.6f3fbcff@rigel.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [devel] RemovePathPostfixes X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 09:41:19 -0000 Archived-At: List-Archive: List-Post: On 2021-02-05 04:31:50 +0300, Alexey Shabalin wrote: > Вы ушли в сторону от обсуждаемой темы RemovePathPostfixes Я ответил на сообщение ldv про то, что множественные Provides - это плохо для репы. Ну а дальше дискуссия продолжилась... :-) > RemovePathPostfixes позволяет по одному пути упаковать разные > файлы в разные бинарные rpm из одного src.rpm пакета. Да, и это очень хорошо. Если пользоваться этой возможностью с умом, можно даже библиотеки так собирать - с заведомо одинаковым ABI, но, например, с разными зависимостями от других библиотек. Единственная сложность, которая здесь может возникнуть - при сборке придется явно указывать, какую библиотеку использовать (имя пакета; так-то понятно, что нужно выбирать сборку с минимальными зависимостями). > Да конфликтующие, но разные и из одного src.rpm. Я не думаю, что > появится еще какая-нибудь реализация systemd-tmpfiles (разве что > найдется герой и напишет её на shell). Могу ошибаться, но вроде что-то похожее мне уже встречалось... не в мейнстримных системах, и даже не в дебилиане с его клонами, а в какой-то экзотике. > Поэтому тут альтернативы лишние, а конфликт в самый раз. Да alternatives везде лишние... но всем как обычно. > Еще забыл упомянуть в первом письме, что вызов systemd-tmpfiles > (и других утилит) может быть в %post у пакета. В случае с sysv > такой пакет уже не установится, точнее будет вытягивать systemd. Возможно, есть смысл не тащить в системы с sysV ошметки systemd, а либо реализовать нужный функционал независимо, либо вообще обойтись без него. > А задача была обратная - предоставить systemd standalone утилиты > для sysv. Теряется унификация для наших пакетов и скриптов. А так ли она нужна? Может, проще будет разграничить их по принципу "юниты налево, скрипты направо"? > Поэтому мне кажется стоит откатить изменения в startup. Если > ничего не выйдет с RemovePathPostfixes, то все равно придется > standalone утилиты собирать "родными" именами (без суфикса > .standalone). Хоть из отдельного src.rpm пакета. Или как-то их объезжать. Вплоть до того, что сделать два разных пакета с Provides: startup > Да конфликтующие с основными утилитами. Да и хрен бы с ними... > Просто RemovePathPostfixes облегчил бы жизнь. Угу. Только использовать его нужно с умом. И очень аккуратно. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net