* [devel] %_libexecdir @ 2022-02-20 8:28 Anton Farygin 2022-02-23 0:19 ` Dmitry V. Levin 0 siblings, 2 replies; 7+ messages in thread From: Anton Farygin @ 2022-02-20 8:28 UTC (permalink / raw) To: ALT Linux Team development discussions Всем привет. А кто-то помнит по каким причинам у нас $ rpm --eval '%_libexecdir' /usr/lib а не /usr/libexec ??? Там было что-то осмысленное, или просто такое legacy, которое менять страшно ? Антон ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAEdvWkTozrzKc6L9EDD2QPLKv4ZoqkmTR=NPWubZ7T9hUSg-Cg@mail.gmail.com>]
* Re: [devel] %_libexecdir @ 2022-02-20 11:34 ` Alexey V. Vissarionov 2022-02-20 11:54 ` Anton Farygin 1 sibling, 0 replies; 7+ messages in thread From: Alexey V. Vissarionov @ 2022-02-20 11:34 UTC (permalink / raw) To: ALT Linux Team development discussions On 2022-02-20 14:31:21 +0300, Alexey Shabalin wrote: >> А кто-то помнит по каким причинам у нас >> $ rpm --eval '%_libexecdir' >> /usr/lib >> а не /usr/libexec ??? >> Там было что-то осмысленное, или просто такое legacy, которое >> менять страшно ? > Вопрос в рассылке возникает регулярно, наверно каждые пару лет. > И все боятся трогать. Приходится в самом спеке переопределять. > Поменяйте уже глобально, пожалуйста. Остается самая малость: выяснить, что при этом поломается. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] %_libexecdir 2022-02-20 11:34 ` Alexey V. Vissarionov @ 2022-02-20 11:54 ` Anton Farygin 2022-02-20 12:09 ` Alexey Shabalin 1 sibling, 1 reply; 7+ messages in thread From: Anton Farygin @ 2022-02-20 11:54 UTC (permalink / raw) To: devel On 20.02.2022 14:31, Alexey Shabalin wrote: > > > вс, 20 февр. 2022 г., 11:28 Anton Farygin <rider@basealt.ru>: > > Всем привет. > > А кто-то помнит по каким причинам у нас > > $ rpm --eval '%_libexecdir' > /usr/lib > а не /usr/libexec ??? > > Там было что-то осмысленное, или просто такое legacy, которое менять > страшно ? > > > > Вопрос в рассылке возникает регулярно, наверно каждые пару лет. > И все боятся трогать. > Приходится в самом спеке переопределять. > Поменяйте уже глобально, пожалуйста. > git grep в specs на %define _libexecdir показывает 323 пакета, которые меняют умолчание. Они точно не сломаются. При этом всего 475 пакетов используют %_libexecdir в секции files. Можно, наверное, их вычислить, поменять дефолт и сделать тестовую пересборку. ну или пройтись по списку этих пакетов и в каждом из них переопределить %_libexecdir, отправить в репозиторий с проверкой. Сотня с небольшим пакетов это не так много, на самом деле. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] %_libexecdir 2022-02-20 11:54 ` Anton Farygin @ 2022-02-20 12:09 ` Alexey Shabalin 0 siblings, 0 replies; 7+ messages in thread From: Alexey Shabalin @ 2022-02-20 12:09 UTC (permalink / raw) To: ALT Linux Team development discussions вс, 20 февр. 2022 г. в 14:53, Anton Farygin <rider@basealt.ru>: > > On 20.02.2022 14:31, Alexey Shabalin wrote: > > > > > > вс, 20 февр. 2022 г., 11:28 Anton Farygin <rider@basealt.ru>: > > > > Всем привет. > > > > А кто-то помнит по каким причинам у нас > > > > $ rpm --eval '%_libexecdir' > > /usr/lib > > а не /usr/libexec ??? > > > > Там было что-то осмысленное, или просто такое legacy, которое менять > > страшно ? > > > > > > > > Вопрос в рассылке возникает регулярно, наверно каждые пару лет. > > И все боятся трогать. > > Приходится в самом спеке переопределять. > > Поменяйте уже глобально, пожалуйста. > > > git grep в specs на %define _libexecdir показывает 323 пакета, которые > меняют умолчание. > > Они точно не сломаются. > > При этом всего 475 пакетов используют %_libexecdir в секции files. Большинство из них вполне переживут переезд файлов в новое место. Чинить надо только те, для которых критично /usr/lib > > Можно, наверное, их вычислить, поменять дефолт и сделать тестовую > пересборку. ну или пройтись по списку этих пакетов и в каждом из них > переопределить %_libexecdir, отправить в репозиторий с проверкой. Сотня > с небольшим пакетов это не так много, на самом деле. > -- Alexey Shabalin ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] %_libexecdir 2022-02-20 8:28 [devel] %_libexecdir Anton Farygin @ 2022-02-23 0:19 ` Dmitry V. Levin 2022-02-23 7:26 ` Anton Farygin 1 sibling, 1 reply; 7+ messages in thread From: Dmitry V. Levin @ 2022-02-23 0:19 UTC (permalink / raw) To: ALT Devel discussion list On Sun, Feb 20, 2022 at 11:28:30AM +0300, Anton Farygin wrote: > Всем привет. > > А кто-то помнит по каким причинам у нас > > $ rpm --eval '%_libexecdir' > /usr/lib > а не /usr/libexec ??? > > Там было что-то осмысленное, или просто такое legacy, которое менять > страшно ? Так было в FHS, это появилось ещё в прошлом веке до создания ALT. Для того, чтобы менять такие древние традиции, надо ответить на два вопроса, зачем и какой ценой. Грубо говоря, от изменения должна быть какая-то существенная польза, перевешивающая затраты на изменение. Неизвестно, есть ли вообще какая-нибудь польза от другого значения макроса, но известно, что трудозатраты на проверку последствий значительные. Как обычно с такими макросами, отследить всё, на что они влияют, довольно сложно, поскольку это не только пакеты, в спеках которых упоминается макрос %_libexecdir, но и пакеты, в спеках которых упоминаются использующие %_libexecdir макросы %configure и %makeinstall (может быть, есть и другие макросы, но про эти два этот факт хорошо известен). Каждый из пакетов, в котором не переопределяется %_libexecdir, но используется один из этих трёх макросов, придётся проверить, не сломается ли он в результате изменения значения %_libexecdir. Таких пакетов примерно 3770. Несколько видов возможных поломок можно представить себе сразу: - пакет перестанет собираться; - в пакет перестанут упаковываться какие-то части, которые сейчас упаковываются; - пакет станет неправильно работать из-за неготовности к изменению; - разные пакеты перестанут правильно взаимодействовать друг с другом из-за того, что изменение не произошло в них синхронно, например, потому что в одном из пакетов используется значение %_libexecdir не из макроса, а зашито прямо в код. В общем, объём потенциальных разрушений велик, и для того, чтобы начинать обсуждать это всерьёз, нужно видеть потенциальную пользу, перевешивающую всё это. -- ldv ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] %_libexecdir 2022-02-23 0:19 ` Dmitry V. Levin @ 2022-02-23 7:26 ` Anton Farygin 2022-02-23 12:27 ` Dmitry V. Levin 0 siblings, 1 reply; 7+ messages in thread From: Anton Farygin @ 2022-02-23 7:26 UTC (permalink / raw) To: devel 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, которому (наверное) было бы неплохо последовать. > > Для того, чтобы менять такие древние традиции, надо ответить на два > вопроса, зачем и какой ценой. Грубо говоря, от изменения должна быть > какая-то существенная польза, перевешивающая затраты на изменение. Соответствие современному стандарту не является ощутимой пользой от такого изменения ? > > Неизвестно, есть ли вообще какая-нибудь польза от другого значения > макроса, но известно, что трудозатраты на проверку последствий > значительные. > > Как обычно с такими макросами, отследить всё, на что они влияют, довольно > сложно, поскольку это не только пакеты, в спеках которых упоминается > макрос %_libexecdir, но и пакеты, в спеках которых упоминаются > использующие %_libexecdir макросы %configure и %makeinstall (может быть, > есть и другие макросы, но про эти два этот факт хорошо известен). Каждый > из пакетов, в котором не переопределяется %_libexecdir, но используется > один из этих трёх макросов, придётся проверить, не сломается ли он в > результате изменения значения %_libexecdir. Таких пакетов примерно 3770. > Несколько видов возможных поломок можно представить себе сразу: > - пакет перестанет собираться; > - в пакет перестанут упаковываться какие-то части, которые сейчас > упаковываются; > - пакет станет неправильно работать из-за неготовности к изменению; > - разные пакеты перестанут правильно взаимодействовать друг с другом из-за > того, что изменение не произошло в них синхронно, например, потому что в > одном из пакетов используется значение %_libexecdir не из макроса, а > зашито прямо в код. > > В общем, объём потенциальных разрушений велик, и для того, чтобы начинать > обсуждать это всерьёз, нужно видеть потенциальную пользу, перевешивающую > всё это. > > Спасибо. Собственно я хотел услышать, является ли проблемой для нас то, что в части пакетов будет использоваться другое содержимое максроса libexecdir ? Судя по всему нет, это проблемой не является, поэтому во всех моих пакетах, где апстрим предполагает что libexecdir смотрит в /usr/libexec - я начинаю переопределять %_libexecdir ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel] %_libexecdir 2022-02-23 7:26 ` Anton Farygin @ 2022-02-23 12:27 ` Dmitry V. Levin 0 siblings, 0 replies; 7+ messages in thread From: Dmitry V. Levin @ 2022-02-23 12:27 UTC (permalink / raw) To: ALT Devel discussion list 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-02-23 12:27 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-02-20 8:28 [devel] %_libexecdir Anton Farygin 2022-02-20 11:34 ` Alexey V. Vissarionov 2022-02-20 11:54 ` Anton Farygin 2022-02-20 12:09 ` Alexey Shabalin 2022-02-23 0:19 ` Dmitry V. Levin 2022-02-23 7:26 ` Anton Farygin 2022-02-23 12:27 ` Dmitry V. Levin
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