[devel] buildreq FRs

[Alexey Tourbin <at@altlinux.ru>]

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

On Sat, Sep 02, 2006 at 07:24:44PM +0300, Michael Shigorin wrote:
> On Wed, Aug 30, 2006 at 08:00:36PM +0400, Alexey Tourbin wrote:
> > (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> > переписке.  Правда, спросонья я потерял к нему интерес.  Если это
> > интересно кому-то ещё, тогда можно перенести обсуждение сюда.)
> 
> Переноси, конечно.  Мне buildreq2 уже однажды здорово помог при
> создании дистрибутивоопределяющей "пустышки".  С меня причитается.

Мне в buildreq не хватало нескольких вещей, вседствие чего и появился
экспериментальный buildreq2.

1) Оптимизация списка пакетов.  У сложных пакетов список не умещался ни
в одну строчку, ни в две, а иногда занимал и больше трёх.  Список был
мало информативным для человека.  Многие редактировали его вручную.
Оптимизация там была, но она была основна на назвинии пакетов, а не на
зависимостях между пакетами (вследствие чего иногда лажалась).

Я писал об этом ещё в 2003 году "buildreq proposal".  Правда, тогда я
не понимал многих вещей, таких как "всякий частичный порядок может быть
дополнен до линейного".  В buildreq2 реализован эвристический алгоритм,
в котором вместо топологической сортировки используется сортировка по
числу зависимостей у пакета.

Теперь я предложил более правильный алгоритм для buildreq.

2) Полный список файлов, которые зацепились при сборке, сгруппированный
по пакетам.  Это сделать несложно, но в рамках нескольких маленьких
скриптов это сложно сделать красиво.

3) Трассировка.  Иногда хочется знать, где именно при сборке цепляется
тот или иной файл, или любой файл из какого-либо пакета.  Здесь есть
неприятные тонкости, потому что имя путей на выходе из strace не
каноникализировано, а каноникализация типа realpath() может дать совсем
другой пакет (если исходный путь -- симлинк).  Дёргать же на каждый файл
rpmdb -- очень дорого.  Опять же возможны подходы (в buildreq2
реализован не совсем корректный), но в рамках нескольких скриптов,
каждый из который "хорошо делает только одну вещь", трудно найти
красивый подход.

UNIX way оказывается недостаточно гибким, когда нужно вклиниться где-то
внутри.

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