ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [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

* 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