Re: [devel] contents_index_*

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 4050 bytes --]

On Wed, Jan 23, 2008 at 03:34:11AM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 23, 2008 at 03:11:39AM +0300, Alexey Tourbin wrote:
> > > Раньше файловая зависимость /usr/share/java/lucene.jar однозначно
> > > разрешалась в пакет lucene.  Теперь в репозитарии есть два пакета --
> > > lucene и lucene1, которые содержат этот файл, поэтому ничего не
> > > остаётся, как только сохранить файловую зависимость as is.
> > > Если же удалить из репозитария пакет lucene1, то опять "восстановится"
> > > зависимость на lucene.
> > > 
> > > Это наводит меня на мысль, что, по идее, сам механизм contents_index_all
> > > в общем-то не нужен.  Результат слишком сильно варьируется от текущего
> > > состояния репозитария.  Если пакет явно требует какой-то файл, то пусть
> > > он просто требует этот файл, а дополнительный шаг по поиску реального
> > > пакета с этим файлом ничего хорошего не даёт, а только "не по делу"
> > > преобразует зависимость (и, кстати, ослабляет гарантию по наличию
> > > соответствующего файла в новых сборках пакета).
> > 
> > Вообще у меня появилась мысль, что contents_index_* -- плохая идея.
> > Результат сборки пакета должен быть функцией от src.rpm'а и содержимого
> > сборочного чрута.  А contents_index_* сейчас позволяет в значительной
> > степени варьировать зависимости у пакета, который собирается в одном и
> > том же чруте, но на разных репозитариях.  Нужно это влияние хотя бы
> > свести к минимуму.
> 
> Каким образом?
> Если файла нет в сборочном чруте, то что написать в зависимость?

Если известен путь к файлу, то дело в шляпе -- можно просто
писать в зависимости путь к файлу.

/usr/lib/rpm/find-package:
   213          # Not found; output raw dependence.
   214          Info "$f: $rep -> $rep (raw, not found)"
   215          printf %s\\n "$rep"

То есть пути просто не надо отображать в названия пакета, который
владеет этим путём.  Тогда не будет зависимости от состояния "внешенего"
по отношению к сборке репозитария.

> Например, в скрипте используется утилита foo, которая неизвестно где в
> $PATH находится, и в сборочном чруте её нет.

А вот когда пути неизвестно, тогда начинается гадание на
кофейной гуще.  Прежде всего, мы хотим выяснить, есть ли вообще
где-то в репозитарии такая утилита.  Если её нигде нет, то
правдоподобнее считать, что у нас левый скрипт.  Это может быть
функция из файла в каком-то другом пакете или adjusted PATH или
что угодно.  Приходится даже подавлять диганостику, потому что
слишком много высыпает:

   378          # Not found.
   379          local maybe_function=
   380          case "$r" in
   381                  *[!A-Za-z0-9_]*) ;;
   382                  [!A-Za-z_]*) ;;
   383                  *[A-Z_]*) maybe_function=1 ;;
   384          esac
   385          if [ -n "$maybe_function" ]; then
   386                  $Verbose "$f: $r not found (skip, maybe function)"
   387          else
   388                  Info "$f: $r not found (skip)"
   389          fi

Кроме "прежде всего" выяснения, есть ли вообще такое дело,
нам нужно также соблюдать баланс между 1) возможностью перемещения
команды между каталогами PATH, из-за чего нежелательно ставить
файловую зависимость; 2) сохранить зависимость достаточно виртуальной,
чтобы облегчить переименование пакетов, из-за чего нежелательно ставить
зависимость на имя пакета.  Понятно, что эти пункты противоречат друг
другу.  Если бы можно было "отсрочить" сразу два этих пункта, тогда бы
мы могли получить бОльшую независимость от contents_index_*.

Можно было бы отсрочить это введением дополнительного неймспеса
зависимостей executable(...) -- возможно, с поддержкой со стороны
rpm и apt.

Но решение есть такой executable в репозитарии или нет (и
соответственно, генерировать вообще зависимость или нет) отсрочить
никак нельзя.  А раз его нельзя отсрочить, то мы неизбежно пользуемся
информацией о том, что такой executable существует в репозитарии, а это
близко связано с тем, какому пакету этот executable принадлежит...

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]