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 оказывается недостаточно гибким, когда нужно вклиниться где-то внутри.