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

[Pavel Nakonechnyi <zorg1331@gmail.com>]

вс, 30 авг. 2020 г. в 12:27, Aleksey Novodvorsky <aen@basealt.ru>:
>
> вс, 30 авг. 2020 г., 13:04 Igor Vlasenko <vlasenko@imath.kiev.ua>:
>>
>> On Sun, Aug 30, 2020 at 12:47:20PM +0300, Aleksey Novodvorsky wrote:
>> > Дистрибутивная -- самостоятельно разворачиваемая из комплекта пакетов.
>>
>> да, тогда это то же самое, что я называл локальной сборочницей.
>>
>> > Но при этом у локальной сборочницу будет свой локальный репозиторий,
>> > синхронизируемый с глобальным, так?
>>
>> Да, один из вариантов использования.
>>
>> Для использования дистрибутивной/локальной сборочницы
>> я вижу 4 основных сценария:
>>
>> 1) оффлайн работа.
>> Пропал интернет, но мы подготовили пакет, и хотим узнать,
>> пройдет ли он тесты. В этом случае новый репозиторий не создается.
>>
>> 2) Сборка пакетов в отдельный репозиторий-оверлей
>> наподобие autoimports (non-free, media, vasya_pupkin_packages)
>> В этом случае новый репозиторий создается и публикуется как оверлей к сизифу.
>>
>> 3) Форк сизифа для каких-то целей, к примеру, исследовательских.
>> К примеру, создаем таск, удаляющий ffmpeg и добавляющий libav
>> (или другое спорное обновление). Смержив его локально с Сизифом,
>> получим локально форк Сизифа с libav вместо ffmpeg.
>> Далее исследуем локально, что же при этом сломалось сломалось.
>> В этом случае новый репозиторий создается локально, но не публикуется.
>>
>> 4) Портирование Сизифа на новую архитектуру.
>> В этом случае новый репозиторий создается и публикуется.
>
> Вообще говоря это такой привычный для эмбедщиков продукт, они его называют SDK. С ростом рынка IoT и другой эмбедщины он будет востребован. А интеграция с глобальным репозиторием  позволит  подойти к решению проблемы жизненного цикла софта для подобных изделий, которая актуальна.
>

Ворвусь со скромным комментарием в дискуссию как раз по этому поводу.
Еще порядка девяти лет назад или больше, когда работал над выпуском
embedded устройств в довольно приличных масштабах, вопрос сборки
прошивок стоял ребром. Имеющиеся тогда и сейчас технологии
автоматизации этого процесса просто ужасны, если вы хотите получить
продукт с известным поведением. То есть когда у вас прошивка состоит
из множества пакетов и вам нужно понять из-за какого пакета (какого
его исходника) проблемы на объекте, вам нужна обратная трассировка по
версии прошивки. Это получилось организовать используя `gear/hasher`
локально, с локальным репозиторием и тупой сборочницей на кривом
скрипте. Если бы такая локальная сборочница была тогда.. масса
человеко-часов и боли было бы сэкономлено.


--
WBR, Pavel