[devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Michael Shigorin]

On Tue, Sep 08, 2020 at 01:03:10PM +0300, Andrey Savchenko wrote:
> Для корректного применения этой опции необходимо иметь
> возможность построить граф сборочных зависимостей для каждого
> подзадания после первого и определить, нет ли в нём пакетов,
> полученных в предшествующих подзаданиях.

Здесь сходу видна один простой достаточно общий случай:
для заданий с одним подзаданием можно просто включать.

> Проблема в том, что, как уже обсуждалось в данной рассылке,
> в общем случае это неразрешимая задача, т.к. зависимости у нас
> есть не только явно на пакеты, но и на другие объекты,
> например, библиотеки или модули pkg-config: это плата, которую
> нам приходится платить за механизм автоматического определения
> зависимостей.

Сейчас на сборочнице включена перепаковка исходного пакета
для выяснения сборочных зависимостей с учётом %ifarch и т.п.;
не помню, получится ли повторно использовать затраты ресурсов
на эту фазу, но вдруг.

При достаточно низкой изменчивости BR может пригодиться и
применение сохранённого списка зависимостей от предыдущей
сборки заданного пакета в этот же репозиторий с обработкой
исключений -- тут опять же может пригодиться сохранённое
время сборки, что-то может быть быстрее просто пересобрать,
чем возиться лишний раз со сборочным окружением.

Но это всё слова...

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info