Система для сборки прошивок для встройки

У меня свой дистр. И именно его мне надо опакечивать и собирать из них образы.

Вот именно что легаси. На ARM нормально приготовленные дистры 4-5 секунд стартуют.

Ну так и сделай слойку из контейнеров, потом в genimage их. Меняешь базовый образ, меняются все образы при пересборке. А если оставить плейсхолдеры на FROM, то ещё проще всё.

Ну то есть фактически «закат солнца в ручную».

Ну тоже вариант.

Хотя мне бы хотелось иметь вариант когда выкачал из репы все зависимости (какой лбраз из чего должен собираться), дальше одной командой build all. Выкачались все исходники нужных версий. Собрался весь тулинг, собрались все бинарные пакеты сложились в репу. Потом из этих бинарей собрались образы. И при повторном запуске собиралось и пересобиралось только то что прилетело по зависимостям.

Мне нужеа именно такая система. Я пишу правила, а она всё это компиляет и собирает. Без эталонных дистров и дублирования.

Yocto пока ближе всего как мне кажется, хотя и придется poky выкинуть.

фактически «закат солнца в ручную».

в каком именно месте он «в ручную», хотелось бы полюбопытствовать?

компоненты собираются в сиае своих проектов, финальные образы - в release engineering пайплайнах.

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

Да, у нас разные каналы поставок и не всё идет в виде прошивок. Что-то ставится на деб-подобные дистры просто апт-ом.

Хотя мне бы хотелось иметь вариант когда выкачал из репы все зависимости (какой лбраз из чего должен собираться), дальше одной командой build all. Выкачались все исходники нужных версий. Собрался весь тулинг, собрались все бинарные пакеты сложились в репу.

Ну, кхе, это сиай называется. Кнопку «сделать всё за2.7бись» каждый пилит себе сам.

Без эталонных дистров

Не понимаю, о чем это. Мы собираем в целевых системах. Что-то кроссом, что-то нативно, так как не каждый вендор предоставляет кросс-компилятор, увы.

Мне нравится pbuilder, но тут скорее всего не подойдет, задача немного другая. Может взять pbuilder за основу и написать свой велосипед для задачи как вариант. Но конечно сначала следует изучить как обычно решаются такие задачи для конкретного стака и железок, потому уже смотреть.

Эммм а зачем выкачивать все из репы? Сборкой пусть специально обученые сервера занимаются (и всяким build all). И даже выкачивать образы не обязательно, пусть сразу на железку заливаются (ну а чо).

Чего вы такие буквальные?

Понятно, что все это автоматом в рамках пайплайна. Я суть пытаюсь передать. Набор правил и движок который их обрабатывает. Вот нужна готовая реализация семантики правил и движок который готов их выполнять. Причем все уже готовое, заточенное на сборку прошивок для железяк. Желательно с минимальным объемом ручной работы.

йокто - монструозная, нужно разбираться, но очень гибкая и в целом похоже то, что надо (концепция слоев, рецепты, метаданные и т.д.). Неясно насчет пакетирования и хранения

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

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

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

Есть ли возможность локально писать код, собирать и быстро проверять создавая прошивку и загружать ее в железо?

Да, там (в екте) есть воркспейсы для этого

При этом не копируя на локалхост миллиард файлов системы сборки.

Тут тебя ждёт ад)

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

Buildroot же портянка из плохо читаемых мейкфайлов.

прошу извинить, мой опыт небольшой в плане чтоб под сотню железок делать, но задача интересная.

Можно не извиняться. Мы тут идеи фонтанируем, а не пытаемся всем понравится.

Можно в 2-х словах, почему пример из yocto - poky for x86 занимает на диске 300гб?

Результат сохранения всего хлама от сборки SDK.

Если были настроены DL_DIR и SSTATE_DIR, то можно снести директорию build и повторить сборку. Если небыли настроены, то перенести эти две директории вне build, настроить и повторить.

Это плата за систему экономии числа пересборок. Сборка каждого рецепта разбито на шаги (аля скачать, распаковать, настроить, скомпилировать, установить, разложить по пакетам, упаковать пакеты), каждый шаг кешируется. А хлам не чистится.

По этому общая рекомендация:

• Настроил DL_DIR и SSTATE_DIR.
• Собрал первый раз.
• Снёс директорию сборки.
• Собрал второй раз.
• Пошёл работать над образом.

Когда иногда возвращаюсь к старым железка с билдрутом - плачу от счастья, насколько же раньше все было просто, понятно, разумно

А почему бы тогда не продолжать использовать buildroot?

А почему бы тогда не продолжать использовать buildroot?

Если бы я решал – рак бы и было. Но у нас тут культ «прогрессивности», тащат любую хрень про которую есть мода что она прогрессивная, почти всегда это создает проблем больше чем решает, в результате тут одни газотурбинные двигатели и сверхпроводники в задачах где десятилетиями справлялись дизеля и вилка в розетку. Причем современные и прогрессивные справлются хуже, от части функций, которые всегда были, пришлось отказаться, зато все убер-соременное внедрено. Понатащили овер9000 сложности и теперь натурально на ровном месте постоянно имеют с этого проблемы и екта одно из таких решений

Если бы я решал – рак бы и было.

Не сразу понял, что опечатка.

культ «прогрессивности»

Хороший термин, утащу себе.

Тогда буду дальше на buildroot сидеть. :^)

Buildroot же портянка из плохо читаемых мейкфайлов

екта – портянка из плохочитаемых псевдопитоновских рецептов ( на самом деле ничуть не лучше мейкфайлов читается, только еще и мода распихивать все по сотне файликов на три строчки чтоб я сам ходил-бродил, складывал это все в своей голове )

то есть мало прочитать рецепт, надо еще провести расследование что нигде не лежит дополнение к этому рецепту, а поискать тут есть где…

А пробовали системы сборки openwrt

о как, а я думал там билдрут. Даже пользовался. Полез почитал, оказалось давно отфоркнулись и теперь это нечто в себе (звуки образования новых нейронных связей)

Меньше всего мне хочется пердолится в самодельные велосипеды с квадратными колесами

тогда yocto. Но пусть в меня бросит камень тот, кто считает что там не придется пердолиться с чужими велосипедами с квадратными колесами :)

Теперь все тоже самое только для рутфс размером в 30мб

тогда, боюсь, у тебя екта не взлетит. Я точно не знаю че там у нее с минималками, но по ощущениям ей даже на минимуме потребуется в 10 раз больше. Но, повторюсь, я такое не пробовал, это – мои фантазии на тему

То есть требования такие, чтобы можно было тонко настраивать под свои нужды

в екте можно что угодно настраивать, но ее сильная сторона – это набор готовых слоев, которые поддерживаются и обновляются. Ты можешь все это делать и сам, но тогда какой прок от екты? Я охотнее поверю в очень кастомный дебиан на 30 мегабайтах, чем в полностью самодельный дистрибутив на екте

Полез почитал, оказалось давно отфоркнулись

Мне казалось, что buildroot – форк от openwrt. Если правильно всё понял, OpenIPC раньше собиралось через OpenWRT, сейчас перешли на buildroot.