Bug 49683

Отсюда вижу два возможных пути:
— принять удар и исправлять все результировавшие FTBFS после;
— попробовать конкретно в hasher выбросить из PATH каталог /bin (и — для rooter — /sbin), что можно сделать кодом в .host/entry или аддоном для /etc/profile.d в специальном пакете для сборочной среды.

Второй путь приведёт к тому, что execvp("awk", *) будет открывать /usr/bin/awk. На сегодняшний день непонятно, помешает ли это чему-нибудь (вдруг всплывёт тот же симптом, но наоборот: будут unmet Requires: /usr/bin/awk?).

(In reply to Arseny Maslennikov from comment #1)
> — попробовать конкретно в hasher выбросить из PATH каталог /bin (и — для
> rooter — /sbin), что можно сделать кодом в .host/entry или аддоном для
> /etc/profile.d в специальном пакете для сборочной среды.

Если это делать в hasher, то что-то вроде:
  if [ ! -L /bin ]; then
      # Sync this with the default /etc/profile shipped with ALT.
      PATH='/usr/bin:/usr/local/bin'
  fi

/etc/profile к такому готов.
Или, может, не каталог проверять, а "если стоит пакет filesystem и его версия >= 3".

а почему бы сразу не поправить и /etc/profile ?

(In reply to Arseny Maslennikov from comment #2)
> Если это делать в hasher, то что-то вроде:
>   if [ ! -L /bin ]; then
>       # Sync this with the default /etc/profile shipped with ALT.
>       PATH='/usr/bin:/usr/local/bin'
>   fi

Если нужно поменять PATH, то почему это изменение должно быть ограничено средой hasher?

Можно ли поменять /etc/profile синхронно с filesystem?

(In reply to Dmitry V. Levin from comment #5)
> Можно ли поменять /etc/profile синхронно с filesystem?

Можно, конечно. :)

(In reply to Dmitry V. Levin from comment #5)
> Можно ли поменять /etc/profile синхронно с filesystem?

Мне кажется, что если мы проверяем на симлинки, то можно поменять до filesystem.

Тоже хотел предложить поменять /etc/profile прямо сейчас.

(In reply to Anton Farygin from comment #3)
> а почему бы сразу не поправить и /etc/profile?

Я допускаю, что кому-то или чему-то такой ход может помешать. Но примеров привести не могу и сам надеюсь, что их нет.

(In reply to Arseny Maslennikov from comment #9)
> (In reply to Anton Farygin from comment #3)
> > а почему бы сразу не поправить и /etc/profile?
> 
> Я допускаю, что кому-то или чему-то такой ход может помешать. Но примеров
> привести не могу и сам надеюсь, что их нет.

Более всего в этом контексте меня беспокоит генератор зависимостей. Обычно PATH используется так, что _неважно_, в каком порядке там два алиасящих друг друга пути, потому что там всего лишь проходит поиск программы, и в этих каталогах, очевидно, они будут одни и те же.

Но вот ситуация в comment 0 показывает, что чему-то не всё равно, и у нас вылезают unmets.

Подозреваю, что самый надёжный способ исключить этот класс проблем — это вообще не с PATH возиться, а все зависимости на исполнимые программы привести к виду executable(/bin/awk) вместо как /bin/awk, так и /usr/bin/awk.

(In reply to Arseny Maslennikov from comment #10)
> Подозреваю, что самый надёжный способ исключить этот класс проблем — это
> вообще не с PATH возиться, а все зависимости на исполнимые программы
> привести к виду executable(/bin/awk) вместо как /bin/awk, так и /usr/bin/awk.

Или реально пройтись по всем пакетам, которые Provides: /bin/что-то, и повесить провайд на /usr/bin/что-то. Зависимости не исчезают, а появляются, поэтому можно в разных транзакциях.

(In reply to Arseny Maslennikov from comment #9)
> (In reply to Anton Farygin from comment #3)
> > а почему бы сразу не поправить и /etc/profile?
> 
> Я допускаю, что кому-то или чему-то такой ход может помешать. Но примеров
> привести не могу и сам надеюсь, что их нет.

По итогам тестовых пересборок получается, что, если в hasher-окружении просто поменять записи в PATH в /etc/profile местами, это сломает гораздо меньше пакетов, чем если этого не делать. Сходу я увидел только, что зависимости на /lib/lsb/init-functions заменяются на /usr/lib/lsb/init-functions, но это начнёт мешать только при попытке пересобрать или обновить пакет => можно решать проблемы по мере их возникновения.

Впрочем, мониторить зависимостей при помощи тестовых пересборок очень трудно, потому что в конце лога успешной пересборки выводится дифф с пакетом в репозитории, а не с чем-то ещё. Полезнее было бы сравнивать с результатом пересборки в сизифе. Когда есть два диффа A->B и A->C, то при наличии объекта A можно получить дифф B->C (интересующий), но этого A нет или я не знаю, где он. Наверное, надо в будущем как-то упростить эту задачу.

Нижеследующий факт гораздо интереснее.
Значение PATH из /etc/profile не имеет эффекта в hasher-окружении, потому что в /etc/profile написано вот так:

  [ -n "$PATH" ] || PATH="/usr/bin:/bin:/usr/local/bin"

Если PATH уже назначена во что-то, это значение будет сохранено.
До этого этапа hasher-priv ставит значение PATH, разное для rooter и builder:
https://git.altlinux.org/gears/h/hasher-priv.git?p=hasher-priv.git;a=blob;f=hasher-priv/chrootuid.c;h=45053d743d9f798bfdf5f337bd895b6c9ea9d029;hb=9f3e5ecebc2a218953cff58c71f3bc07534c58bd#l270-285

Выглядит это так:
  % hsh-run -- /bin/sh -c 'echo $PATH'
  /bin:/usr/bin:/usr/X11R6/bin
  % hsh-shell <<<'echo $PATH'
  echo $PATH
  [builder@localhost .in]$ echo $PATH
  /usr/src/bin:/usr/bin:/bin:/usr/games
  [builder@localhost .in]$ 
  logout
В первом случае остаётся значение от hasher-priv (/etc/profile даже не задействуется), во втором случае используется /etc/profile, в начале которого явно задано "PATH=/usr/bin:/bin". Более того, скорее всего, для процессов от rooter используется значение из пакета rootfiles, файл вообще не profile, а bashrc:
https://git.altlinux.org/gears/r/rootfiles.git?p=rootfiles.git;a=blob;f=rootfiles/.bashrc;h=385d4978963bc1830c63123e80c1ebe8f5d11c42;hb=3e1b5ad151b6c53e1ad563659eb7df6a1428ba7d
и перебивает всю аккуратную логику, описанную выше.

Если задуматься, то это глубоко неправильно хотя бы потому, что один и тот же hasher-priv используется для сборки в окружении разных наших репозиториев.

(In reply to Arseny Maslennikov from comment #13)
> Более того, скорее всего, для
> процессов от rooter используется значение из пакета rootfiles, файл вообще
> не profile, а bashrc:
> https://git.altlinux.org/gears/r/rootfiles.git?p=rootfiles.git;a=blob;
> f=rootfiles/.bashrc;h=385d4978963bc1830c63123e80c1ebe8f5d11c42;
> hb=3e1b5ad151b6c53e1ad563659eb7df6a1428ba7d
> и перебивает всю аккуратную логику, описанную выше.

Это если hsh-shell --rooter запустить. В окружении под hsh-run /etc/profile всегда игнорируется, PATH всегда получается от hasher-priv.

(In reply to Arseny Maslennikov from comment #13)
> Нижеследующий факт гораздо интереснее.
> Значение PATH из /etc/profile не имеет эффекта в hasher-окружении, потому
> что в /etc/profile написано вот так:
> 
>   [ -n "$PATH" ] || PATH="/usr/bin:/bin:/usr/local/bin"

Видимо, эту проверку на [ -n ] надо будет убрать, если она больше ни для чего не нужна.

https://packages.altlinux.org/tasks/344893/
https://packages.altlinux.org/tasks/345302/