From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 23 Feb 2022 15:27:30 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Message-ID: <20220223122730.GA24490@altlinux.org> References: <20220223001910.GA16644@altlinux.org> <9068cf54-7ead-6601-b071-722bff60c8d6@basealt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9068cf54-7ead-6601-b071-722bff60c8d6@basealt.ru> Subject: Re: [devel] %_libexecdir 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: Wed, 23 Feb 2022 12:27:30 -0000 Archived-At: List-Archive: List-Post: On Wed, Feb 23, 2022 at 10:26:10AM +0300, Anton Farygin wrote: > On 23.02.2022 03:19, Dmitry V. Levin wrote: > > On Sun, Feb 20, 2022 at 11:28:30AM +0300, Anton Farygin wrote: > >> Всем привет. > >> > >> А кто-то помнит по каким причинам у нас > >> > >> $ rpm --eval '%_libexecdir' > >> /usr/lib > >> а не /usr/libexec  ??? > >> > >> Там было что-то осмысленное, или просто такое legacy, которое менять > >> страшно ? > > Так было в FHS, это появилось ещё в прошлом веке до создания ALT. > Т.е. - это изменение в FHS, которому (наверное) было бы неплохо последовать. > > > > Для того, чтобы менять такие древние традиции, надо ответить на два > > вопроса, зачем и какой ценой. Грубо говоря, от изменения должна быть > > какая-то существенная польза, перевешивающая затраты на изменение. > Соответствие современному стандарту не является ощутимой пользой от > такого изменения ? А что по этому поводу говорит нынешний стандарт? Если он не запрещает паковать executables в /usr/lib/, то мы соответствуем. > > Неизвестно, есть ли вообще какая-нибудь польза от другого значения > > макроса, но известно, что трудозатраты на проверку последствий > > значительные. > > > > Как обычно с такими макросами, отследить всё, на что они влияют, довольно > > сложно, поскольку это не только пакеты, в спеках которых упоминается > > макрос %_libexecdir, но и пакеты, в спеках которых упоминаются > > использующие %_libexecdir макросы %configure и %makeinstall (может быть, > > есть и другие макросы, но про эти два этот факт хорошо известен). Каждый > > из пакетов, в котором не переопределяется %_libexecdir, но используется > > один из этих трёх макросов, придётся проверить, не сломается ли он в > > результате изменения значения %_libexecdir. Таких пакетов примерно 3770. > > Несколько видов возможных поломок можно представить себе сразу: > > - пакет перестанет собираться; > > - в пакет перестанут упаковываться какие-то части, которые сейчас > > упаковываются; > > - пакет станет неправильно работать из-за неготовности к изменению; > > - разные пакеты перестанут правильно взаимодействовать друг с другом из-за > > того, что изменение не произошло в них синхронно, например, потому что в > > одном из пакетов используется значение %_libexecdir не из макроса, а > > зашито прямо в код. > > > > В общем, объём потенциальных разрушений велик, и для того, чтобы начинать > > обсуждать это всерьёз, нужно видеть потенциальную пользу, перевешивающую > > всё это. > > > > > Спасибо. > > Собственно я хотел услышать, является ли проблемой для нас то, что в > части пакетов будет использоваться другое содержимое максроса libexecdir ? > > Судя по всему нет, это проблемой не является, поэтому во всех моих > пакетах, где апстрим предполагает что libexecdir смотрит в /usr/libexec > - я начинаю переопределять %_libexecdir Я не вижу в этом проблемы и сам в отдельных случаях пакую executables внутрь /usr/libexec/ уже достаточно давно, например, каталог /usr/libexec/hasher-priv существует уже 17 лет, а сам каталог /usr/libexec был упакован в пакет filesystem без малого 20 лет назад. -- ldv