[devel] Requires vs. contents_index

[devel] Requires vs. contents_index

[Grigory Batalov]

Здравствуйте!

Так сложилось, что findreq при наличии локального репозитария с пакетами вычисляет
по contents_index несколько больше зависимостей, чем указано в spec-файле пакета
директивами Requires. Поэтому не все мэйнтейнеры следят за актуальностью этих
Requires, потому что "само всё найдётся".

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

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

Re: [devel] Requires vs. contents_index

[Alexey Tourbin]

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

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-ом зависимостями?

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

Есть ещё одна проблема.  Урезать список автоматических зависимостей
несколько сложнее, чем наращивать этот список.

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