On Tue, Mar 13, 2007 at 12:49:52AM +0300, Dmitry V. Levin wrote:
> > Кроме того, пакет git не собирается, потому что там в некоторых
> > шелл-скриптах после `exit 0' идет некомментированный plain text.
> 
> Тогда почему до изменения пакет git собирается?

Речь идет о файле /usr/share/git-core/templates/hooks/pre-rebase.
Раньше зависимости искались только в исполняемых shell файлах,
а этот файл не исполняемый, и поэтому пакет собирался.

Мне эта схема с исполняемостью не очень нравится.  Потому что нет
способа отличить шелл скрипты, который должны быть исполняемыми, от
библиотеки шелл-функций, которые желательно чтобы не были исполняемыми.

Кстати, например, в пакете service используется хак.
/etc/rc.d/init.d/functions находится в билдруте в исполняемом состоянии,
и поэтому зависимости в нём ищутся, а в cpio заворачивается уже в
неисполняемом состоянии через %attr.

Посмотрим на эту проблему с другой стороны: в чем в данном случае её
суть?  Суть в том, что обнаружились некие *настоящие* шелл-скрипты,
которые не проходят стандартной проверки `sh -n'.  С этой точки зрения
никакой специальной проблемы с поиском зависимостей как бы и нет.
Просто мы узнали то, на что раньше не обращали внимания.

В общем, я думаю, что в случае необходимости нужно явно отключать поиск
зависимостей в конкретных файлах, а не полагаться на исполняемость.
И сомнительно, чтобы в случае с git эта необходимость была.

А как решить эту проблему я подумаю, проще всего наверное будет добавить
проверку на ещё один частный случай в shell.req, наравне с exec в первой
строчке.

> > Кроме того, будут проблемы с питоном, потому что `#!/usr/bin/env python'
> > теперь отыскиваются слишком хорошо.
> 
> Что значит "слишком хорошо" и что значит "будут проблемы с питоном"?

Слишком хорошо означает что для #!/usr/bin/env python будет вызван
FindPackage "$f" /usr/bin/env python.

$ /usr/lib/rpm/shebang.req -v /usr/lib/rpm/python.req.py 
shebang.req: /usr/lib/rpm/python.req.py: /usr/bin/env -> coreutils (via rpmdb)
coreutils
shebang.req: /usr/lib/rpm/python.req.py: python -> /usr/bin/python -> ... (via which)
shebang.req: /usr/lib/rpm/python.req.py: /usr/bin/python -> python-strict (via rpmdb)
python-strict
$

А пакет python-strict, грубо говоря, требует все остальные пакеты, на
которые распилен питон.  Последнее явно неприемлемо для базовой
сборочной системы (тогда как внесение python-base в базовую систему
кажется мне приемлемым).

У пакета rpm-build-python вообще никакой зависимости на python нету,
т.е. это такой дохляк, который прямо начиная с #! может не запуститься
и отвалить, а это противоречит нашему принципу что всё более-менее
должно работать из коробки без всяких там грубых посыланий и доустановок.

Хуже того, если я правильно понимаю, то скрипты из rpm-build-python
всячески скрывают свои зависимости, и если им чего-то не хватает, то они
отваливают абсолютно тихо, по-подлому.

python.req:
    35  try :
    36      import sys, os
    37      import parser, symbol, token, types
    38  except :
    39      pass    
    40  else :    

После else идет весь реальный код.  Такая же история с python.prov.py.
Т.е. мы можем не только недосчитаться requires зависимостей, но и
пропустить provides зависимости, а это уже чревато анметами в
репозитарии.  И, как известно, в репозитарии больше всего именно
питоновских анметов.  В общем, такой лажи быть не должно.

Резюмирую, что мне кажется рационально нужно сделать с питоном.

1) пересмотреть как питон распилен.  python-base должен давать работающий
/usr/bin/python и достаточно модулей для работы rpm-build-python.  Тогда
можно раскрыть зависимости в rpm-build-python и внести python-base в
базовую сборочную систему.

2) Изменить rpm-build-python чтобы если там чево-то отваливает то чтобы
хотя бы сообщал, что, мол, отваливаю, и чево не хватает.  А ещё лучше
чтобы просто отваливал, как следует.