[devel] железо на сборочнице

[Anton Farygin]

21.03.2019 3:31, Dmitry V. Levin пишет:
> On Wed, Mar 20, 2019 at 04:05:55PM +0300, Dmitry V. Levin wrote:
>> On Wed, Mar 20, 2019 at 03:01:53PM +0200, Igor Vlasenko wrote:
>>> On Wed, Mar 20, 2019 at 03:28:16PM +0300, Dmitry V. Levin wrote:
>>>> On Wed, Mar 20, 2019 at 12:09:20PM +0200, Igor Vlasenko wrote:
>>>> [...]
>>>>> а надо бы только при появлении unmets.
>>>> Почему?
>>> Как бы мне и так очевидно, что
>>> пересборка по критерию, входит ли пакет A в сборочное окружение
>>> пакета B изначально была ошибочным допущением.
>> Я считаю иначе.
> Уточню: я считаю очевидным, что если сборочная среда пакета в задании
> изменилась, то этот пакет подлежит пересборке.  Если пакет в результате
> пересборки изменился, то все касающиеся его тесты подлежат перепроверке.
>
> Более того, я считаю очевидным, что если свежесобранный пакет входит в
> сборочную среду других пакетов, то все они должны быть незамедлительно
> пересобраны и перепроверены.  К сожалению, это у нас ещё не реализовано.
Мне кажется, что надо идти по самому простому пути - и сейчас 
распараллеливание install check даст очень много свободного времени 
сборочницы заданиям, в которых эта проверка занимает несущественное время.

Ну и при всей критике нашей сегодняшней сборочницы - не стоит забывать, 
что реально она сейчас работает на оборудовании десятилетней давности и 
узкое место при этом не x86, а aarch64.

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

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