Comments 15
Не совсем понятно, по какой причине вам приходится вручную устанавливать пакеты. Не знаю насчет Yocto, но в OpenWRT Buildroot можно отметить, какие пакеты попадут в rootfs. Неужели Yocto умеет собирать только базовую ФС, и все приходится устанавливать вручную? Или все сложнее, и вы ставите таким образом софт, которого нет в стандартной поставке, или который не хочется компилировать?
Конечно не хочется. Речь идет о промышленном применении. Допустим имеется образ rootfs. Отлаженный образ, обросший прикладным ПО и специфичными настройками. Прикладное ПО разрабатывают, собирают и ведут люди в разных отделах дружного коллектива. Образ тиражируется на серийных устройствах. И тут понадобилось заказчику поставить туда стандартный minicom. Зачем ВСЕ перекомпилировать? А если учесть, что с последней компиляции сменилась версия компилятора, то придется тестировать все бинарники. Ну и, конечно же, время. Компиляция образа занимает не один час, требует дискового пространства, и, конечно же, на хосте должно быть установлено все окружение для кросс-компиляции.
Э? А образ-то вы откуда взяли, не путем компиляции, что ли? В OpenWRT достаточно поставить нужную галку, и он пересоберет образ со включенным minicom, скомпилировав только его, а остальные пакеты просто скопировав, они же уже скомпилированные. И toolchain он вам сам соберет, если нужно. Разве сейчас кто-то собирает иначе, вручную?
Всё это прекрасно, когда собирает всё один отдел. Тот же опенврт обновляется. Вот собирал rootfs один отдел 4 года назад. Люди уже поувольнялись, сами исходники где-то в архивах лежат. Народ дальше пилит софт под эту сборку. И тут внезапно понадобилось поставить один пакетик.
Уверяю, поднять из архивов старую сборку иной раз не представляется возможным. В особенности, если она как-то хитро сконфигурирована, написаны свои драйвера, особые скрипты и т.п. Можно конечно поднять сборку из архивов, но если там какие-то причуды, которые реализовал криворукий программист, который уволился, то времени на то, чтобы развернуть систему может уйти месяцы. Даже если программист работает, то он мог давно всё забыть. Поэтому изобретение таких граблей в большой компании вполне себе достойный выход.
Уверяю, поднять из архивов старую сборку иной раз не представляется возможным. В особенности, если она как-то хитро сконфигурирована, написаны свои драйвера, особые скрипты и т.п. Можно конечно поднять сборку из архивов, но если там какие-то причуды, которые реализовал криворукий программист, который уволился, то времени на то, чтобы развернуть систему может уйти месяцы. Даже если программист работает, то он мог давно всё забыть. Поэтому изобретение таких граблей в большой компании вполне себе достойный выход.
То, что собирают некие «отделы», а не система сборки, и что исходники в архивах лежат, говорит только о неорганизованности. У shamrel, судя по его ответу ниже, все лучше. Образ, в общем случае, не должен редактироваться вручную, его должна собирать система сборки до того состояния, которое вам нужно. В том же OpenWRT Buildroot это решается простым копированием нужных конфигурационных файлов в специальную директорию, которая она потом включает в конечный образ. Как правило, пересборка образа занимает несколько десятков секунд.
Это может говорить о чём угодно. Я готов ради эксперимента дать какой-то чужой образ, с дровами и прочими костылями. И попрошу добавить в него всего один пакетик. При этом не упомяну, что программист был наркоманом и любил пописать свои скрипты для сборки. Плюс компилятор, был удалён и ещё какие-нибудь грабли. Я не могу сейчас перечислить всех граблей, которые подстерегают. Т.к. стараюсь негативные вещи забыввать, но помню что такие подходы столько кровищи пьют, что велосипеды бывают нужны.
Всё это хорошо рассуждать нежно сидя в своём кресле, и работая со свежей сборкой, а не со сборкой 4-х летней давности, покрытой мхом.
К слову сказать, никто не говорит что подход автора расово верный. Я убеждён, что это грабли велосипедные. Но иной раз лучше это, чем провалить сроки.
З.Ы. Иной раз, программисты не кидают свои драйвера в общую сборку, а переписывают их ручками, думая что «все догадаются». Ну забыли включить в конечную сборку. Ты берёшь такую сборку, не думая что дрова у прогера лежат отдельно. Собираешь, и почему-то у тебя не работает какое-то важное устройство, а то и вообще вся сборка не пашет. И тут начинаешь курить. Да, программера бить бичём, но толку?
Всё это хорошо рассуждать нежно сидя в своём кресле, и работая со свежей сборкой, а не со сборкой 4-х летней давности, покрытой мхом.
К слову сказать, никто не говорит что подход автора расово верный. Я убеждён, что это грабли велосипедные. Но иной раз лучше это, чем провалить сроки.
З.Ы. Иной раз, программисты не кидают свои драйвера в общую сборку, а переписывают их ручками, думая что «все догадаются». Ну забыли включить в конечную сборку. Ты берёшь такую сборку, не думая что дрова у прогера лежат отдельно. Собираешь, и почему-то у тебя не работает какое-то важное устройство, а то и вообще вся сборка не пашет. И тут начинаешь курить. Да, программера бить бичём, но толку?
А если не использовать OpenWRT или другой проект «под ключ»? А образ больше чем на половину состоит из кастомного ПО, которого по определению нет в открытых репозиториях? А если аппаратная платформа тоже своя, и в ней железо, поддержку которого только предстоит включить в ядро? Не раз бывало, что в прототип входят чипы с пометкой «Release Engineer», а производитель его еще только допиливает. А еще можно представить, что на производстве не одно изделие, и для каждого своя прошивка. А еще, если предприятие коммерческое и выпускает конкурентный продукт, то задержка выхода на рынок продукта может обернутся боком. И просто, иногда банально, нет времени на допил системы сборки.
Допустим, ты знаешь, что образ для изделия B должен отличается от образа да изделия A только несколькими пакетами, причем отлаженными уже в изделии С, то проще и быстрее взять образ изделия А, запустить opkg, удалить лишнее и установить недостающее.
К сожалению, инженерия в современных реалиях — это искусство компромиссов.
Допустим, ты знаешь, что образ для изделия B должен отличается от образа да изделия A только несколькими пакетами, причем отлаженными уже в изделии С, то проще и быстрее взять образ изделия А, запустить opkg, удалить лишнее и установить недостающее.
К сожалению, инженерия в современных реалиях — это искусство компромиссов.
А если не использовать OpenWRT или другой проект «под ключ»?Так вы же сами Yocto используете, к чему такой вопрос?
А образ больше чем на половину состоит из кастомного ПО, которого по определению нет в открытых репозиториях?Как он устанавливался, в обход пакетного менеджера? Там же есть какая-то система сборки? В этом случае, он добавляется в меню buildroot в течение 15 минут.
А если аппаратная платформа тоже своя, и в ней железо, поддержку которого только предстоит включить в ядро?А сейчас как оно работает?
К сожалению, инженерия в современных реалиях — это искусство компромиссов.Пока я только вижу, что у вас, по какой-то причине, нежелание использовать готовые и быстрые инструменты. Я с buildroot разобрался за день, зато потом смог генерировать любой образ с любыми нужными настройками в течение секунд, а не вспоминать, где у меня что лежит, где какие пакеты, и что мне нужно добавить вручную. Причем считаю себя новичком в embedded.
Берете yocto. Добавляете свои layers и архитектуру через нее, запускаете компиляцию и пьете чай. Кстати да потом если надо тот же результат получить, берете тот же релиз yocto и свои слои и собираете по новой. Не ну правда для вас инструментов наделали. Причем в случае yocto все предельно вылизано и работает из коробки.
И тут я благополучно беру yocto/openEmbedded которым был собран rootfs, далее говорю собери мне пакет и сгенерируй репозиторий. Причем чтоб еще меньше головняка у клиента было, то еще и сделаю пакет со своим репозиторием. Далее если у клиента есть сеть на устройстве, то просто говорим мы там пакет залили поставьте штаными средствами opkg ли бо же скачайте и пихните на девайс. Это уж давно автоматизировано.
Неплохо. И смысл задумки понятен, но почему-то он всё равно отдаёт граблями. Почему автор не пересобирает систему мне тоже понятно. Лично я сталкивался с тем, что «работает — не трогай». Иногда, чтобы заново пересобрать систему требуется месяцы работы, тогда как поставить пакетики — пару дней.
У меня вопрос, почему нельзя сделать образ rootfs, который бы имел разовый скрипт для установки этих пакетов. Что берёшь, заливаешь в систему и при первом запуске идёт установка пакетов, а потом автоматическая конфигурация? Я давно не брал в руки шашек, но помню что в /etc есть загрузочный файлик, которому можно доверить этот геммор. Да, я понимаю что это тоже велосипед, но он более надёжен.
И если можно, распишите подробнее о «фантомных болях», т.к. если железо идентично, то по идее всё должно работать как часы. Тем более, если rootfs находится в режиме ro.
У меня вопрос, почему нельзя сделать образ rootfs, который бы имел разовый скрипт для установки этих пакетов. Что берёшь, заливаешь в систему и при первом запуске идёт установка пакетов, а потом автоматическая конфигурация? Я давно не брал в руки шашек, но помню что в /etc есть загрузочный файлик, которому можно доверить этот геммор. Да, я понимаю что это тоже велосипед, но он более надёжен.
И если можно, распишите подробнее о «фантомных болях», т.к. если железо идентично, то по идее всё должно работать как часы. Тем более, если rootfs находится в режиме ro.
У меня вопрос, почему нельзя сделать образ rootfs, который бы имел разовый скрипт для установки этих пакетов. Что берёшь, заливаешь в систему и при первом запуске идёт установка пакетов, а потом автоматическая конфигурация? Я давно не брал в руки шашек, но помню что в /etc есть загрузочный файлик, которому можно доверить этот геммор. Да, я понимаю что это тоже велосипед, но он более надёжен.
Действительно, systemd обладает таким механизмом. И, признаться честно, те пакеты, которые требуют выполнение preinst я доверил устанавливать ему при первом запуске системы. Но с большинством пакетов, так поступать для нас оказалось нецелесообразно:
1. Каждая версия «прошивки», читай образ NAND, имеет свой номер и жестко контролируется (в некоторых случаях, md5 образа прописана в сертификате соответствия). Должна быть полная уверенность, что все то, что стоит на опытном образце, пойдет в серийный прибор: не больше и не меньше. Поэтому ни о какой «доустановки» пакетов из вне после прошивки не может быть и речи. Прибор может оперировать только теми данными, которые в нем есть после прошивки. Потому исходные пакеты должны быть уже включены в образ. А раз они уже в образе, то почему бы их не инсталлировать ДО старта системы, а не ПОСЛЕ? Отсюда второй аргумент:
2. При серийном производстве время, проведенное прибором на сборочном участке отражается на его себестоимости. Установка большого количества пакетов при первом запуске увеличит это время. (практика показала, что значительно)
3. При включении исходных пакетов в образ, необходимо в ручном режиме следить, что бы все зависимые пакеты были тоже включены. Не проще ли это доверить opkg?
А по поводу «фантомных болях»: например, ключи шифрования (а их у нас их много разных), неочищенные кэши, временные файлы и lock файлы процессов. Спору нет, оно все лечится.
У меня вопрос, почему нельзя сделать образ rootfs, который бы имел разовый скрипт для установки этих пакетов.
А зачем? Если на момент сборки rootfs известны пакеты которые туда попадут, то проще сразу с установленными пакетами его сделать.
Sign up to leave a comment.
Менеджер пакетов opkg. Offline инсталляция пакетов в образ корневой файловой системы