[devel] %_libexecdir

[Dmitry V. Levin]

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