On Sun, Sep 03, 2006 at 08:36:15AM +0400, Alexey Tourbin wrote:
> 1) Низкоуровневый подход (в меньшей степени).  Добавить и использовать
> специальную опцию в packageof.  Для каждого заданного файла, помимо 
> того, чтобы пробивать его по rpmdb, нужно специальным образом
> обрабатывать симлинки.  А именно, для каждого симлинка делать realpath()
> и полученный путь ещё раз пробивать по rpmdb.
> 
> Какой недостаток у этого подхода?  Это вопрос философский. :)
> То есть недостаток довольно тонкий -- настолько тонкий, что не является
> препятствием для реализации, но непременно подлежит обсуждению.
> 
> Речь идет о том, что при использовании симлинка используется не cтолько
> сам симлинк, сколько файл, на который показывает симлинк (симлинк и файл
> могут находится в разных пакетах).  При этом симлинк может показывать,
> вообще говоря, куда угодно.  Я ведь исхожу из того, что мы достраиваем
> цепочку "вовнутрь", то есть вглубь дерева, а симлинк можеть дать
> результат и "вовне".  Здесь можно представить себе альтернативы.
> То есть можно на выходе получить слишком специфические зависимости.

Вот типичная ситуация, в которой проявляется этот недостаток.
/usr/lib/rpm/brp-bytecompile_python:

    27  if [ -n "$RPM_PYTHON" -a -x "$RPM_PYTHON" ] && [ `find -type f -name \*.py |wc -l` -gt 0 ]; then
    28          echo "Bytecompiling python modules in $PWD using $RPM_PYTHON"

Здесь делается stat (точнее, access) на /usr/bin/python.  Этот файл
не принадлежит ни одному из пакетов.  Но если следовать правилу
"требование на симлинки распространяется также на файлы, на которые
показывают симлинки", тогда при использовании buildreq -bi в
BuildRequires появится зависимость на текущий питон, установленный
в системе.

Поэтому задача усложняется: не следует применять это правило для
системных вызовов stat, lstat и access.  Альтернативный вариант:
правильно не следует приминять, если симлинк не принадлежит какому-либо
пакету.