* Re: [devel] Requires vs. contents_index
2009-03-13 11:46 [devel] Requires vs. contents_index Grigory Batalov
@ 2009-03-13 16:37 ` Alexey Tourbin
0 siblings, 0 replies; 2+ messages in thread
From: Alexey Tourbin @ 2009-03-13 16:37 UTC (permalink / raw)
To: devel
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread