Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey Tourbin <alexey.tourbin@gmail.com>]

On Sun, Aug 30, 2020, 13:04 Igor Vlasenko <vlasenko@imath.kiev.ua> wrote:
> On Sun, Aug 30, 2020 at 12:47:20PM +0300, Aleksey Novodvorsky wrote:
> > Дистрибутивная -- самостоятельно разворачиваемая из комплекта пакетов.
>
> да, тогда это то же самое, что я называл локальной сборочницей.
>
> > Но при этом у локальной сборочницу будет свой локальный репозиторий,
> > синхронизируемый с глобальным, так?
>
> Да, один из вариантов использования.
>
> Для использования дистрибутивной/локальной сборочницы
> я вижу 4 основных сценария:
>
> 1) оффлайн работа.
> Пропал интернет, но мы подготовили пакет, и хотим узнать,
> пройдет ли он тесты. В этом случае новый репозиторий не создается.

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

В общем, рассуждения о том, что любая кухарка должна быть способна
развернуть сборочную систему и внести посильный вклад в ПСПО для ЭВМ,
кажутся мне немного наивными. И это нечестный аргумент в пользу
распиливания на дистрибутивные куски. Но могут быть и честные
аргументы: например, улучшить декомпозицию и выделить API. Только
декомпозиция и API на каждый чих сделают конструкцию менее гибкой и
более громоздкой. Монолитный скрипт, который просто работает, имеет
свои преимущества.

> 2) Сборка пакетов в отдельный репозиторий-оверлей
> наподобие autoimports (non-free, media, vasya_pupkin_packages)
> В этом случае новый репозиторий создается и публикуется как оверлей к сизифу.
>
> 3) Форк сизифа для каких-то целей, к примеру, исследовательских.
> К примеру, создаем таск, удаляющий ffmpeg и добавляющий libav
> (или другое спорное обновление). Смержив его локально с Сизифом,
> получим локально форк Сизифа с libav вместо ffmpeg.
> Далее исследуем локально, что же при этом сломалось сломалось.
> В этом случае новый репозиторий создается локально, но не публикуется.
>
> 4) Портирование Сизифа на новую архитектуру.
> В этом случае новый репозиторий создается и публикуется.