[devel] buildreq FRs

[Alexey Tourbin]

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 оказывается недостаточно гибким, когда нужно вклиниться где-то
внутри.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20060903/ddccfa42/attachment-0001.bin>