[devel] Requires vs. contents_index

[Alexey Tourbin]

On Fri, Mar 13, 2009 at 02:46:48PM +0300, Grigory Batalov wrote:
> Так сложилось, что findreq при наличии локального репозитария с пакетами вычисляет
> по contents_index несколько больше зависимостей, чем указано в spec-файле пакета
> директивами Requires. Поэтому не все мэйнтейнеры следят за актуальностью этих
> Requires, потому что "само всё найдётся".

Давайте расставим точки над и.
Речь идёт об алгоритме /usr/lib/rpm/find-package.
Этот алгоритм используется в двух случаях:

1) Когда нужно отобразить ПОЛНЫЙ ПУТЬ к файлу в зависимость.  Можно
считать, что в этом случае зависимость ДОЛЖНА принять вид ПУТИ К ФАЙЛУ
(похожий на исходный путь к файлу).  Разница между исходным путём и
зависимостью может получиться из-за того, что необходимо выполнять
нетривиальную каноникализацию.

Например, путь
/etc/init.d/functions
будет отображен в зависимость
/etc/rc.d/init.d/functions

На самом деле сейчас не все исходные пути принимают вид
зависимостей-путей, хотя и должны; но это дело времени.

2) Когда нужно отобразить КОМАНДУ, предположительно из стандартных
каталогов PATH, в имя зависимости.  Сейчас такие зависимости ищутся
только для shell-скриптов (/usr/lib/rpm/shell.req).  В этом и только
в этом случае используется поиск по contents_index.  КОМАНДЫ обычно
отображаются в ИМЯ ПАКЕТА, если это возможно без двусмысленностей.

Например, команда "cat" будет отображена в зависимость
cat -> /bin/cat -> coreutils
а "двусмысленная" команда "emacs" будет отображена в зависимость
emacs -> /usr/bin/emacs (альтернатива) -> /usr/bin/emacs

(Возможны ещё более двусмысленные случаи, для обработки которых
реализована некая имеющая смысл логика.)

> Однако, при самостоятельной пересборке с удалённым репозитарием пакета из git
> вычисления по contents_index не происходит. В результате скрипты из пакета могут
> не работать, поскольку основываются на отсутствующих компонентах.

Необходимо сделать так, чтобы сборка на локальном репозитарии и на
удаленном репозитарии давала идентичный результат.  Это не очень сложно,
но и не очень просто.  По крайней мере, раз это сделать можно, то это
сделать необходимо.  Требуется несколько синхронных изменений в
rpm-build, hasher, apt-utils и sisyphus (в алгоритме генерации
репозитария для нескольких архитектур).

Остается тогда актульный вопрос, когда это будет сделано.  Алексей
Турбин не регламентирует свою деятельность и возможность повлиять на неё.
Тем не менее, такая возможность существуют.  В хорошем смысле слова.
(В частности, например, имело бы смысл описать конкретную ситуацию.)

> Вопрос: Какова текущая политика заполнения Requires? Следует ли дополнять список
>         автоматически найденными findreq-ом зависимостями?

Политика простая: ограничиваться автоматическими зависимостями, если они
дают приемлемый результат.  Если же приемлемого результата не
получается, то можно наращивать список зависимостей вручную, а также
думать, можно ли улучшить автоматику или нет.

Есть ещё одна проблема.  Урезать список автоматических зависимостей
несколько сложнее, чем наращивать этот список.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090313/d86c9bfb/attachment-0001.bin>