Александр Рыжов

Как я пока что понимаю, несмотря на присутствие в base-files скриптов /lib/functions, OpenWrt'шный механизм не будет использоваться ни для конфигурирования пакетов, ни для запуска сервисов, т.к. для запуска выбрана NSLU-like схема /opt/etc/init.d/Sxx. Соответсвенно, Makefile'ы для половины пакетов всё равно придётся править, хотя бы ради добаваления скриптов запуска.

Насколько понимаю, сейчас среда NDM Systems Buildroot сделана так, чтобы как можно меньше отличаться от OpenWrt Buildroot. Пакеты конфигурируются, компилируются и пакуются без упоминания префикса /opt, что позволяет использовать Makefile'ы OpenWrt'шных пакетов без какой-либо модификации, а для распаковки на роутере в конфиге opkg.conf указывается опция dest root /opt. В частности, вижу в билдруте NDM: $ cat include/package-defaults.mk ... CONFIGURE_PREFIX:=/usr CONFIGURE_ARGS = \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_TARGET_NAME) \ --build=$(GNU_HOST_NAME) \ --program-prefix="" \ --program-suffix="" \ --prefix=$(CONFIGURE_PREFIX) \ --exec-prefix=$(CONFIGURE_PREFIX) \ --bindir=$(CONFIGURE_PREFIX)/bin \ --sbindir=$(CONFIGURE_PREFIX)/sbin \ --libexecdir=$(CONFIGURE_PREFIX)/lib \ --sysconfdir=/etc \ --datadir=$(CONFIGURE_PREFIX)/share \ --localstatedir=/var \ --mandir=$(CONFIGURE_PREFIX)/man \ --infodir=$(CONFIGURE_PREFIX)/info \ $(DISABLE_NLS) \ $(DISABLE_LARGEFILE) \ $(DISABLE_IPV6) Получается, что пакеты, которые конфигурируются с помощью GNU Build System (половина, а то и большинство) получат в своих бинарниках hardcoded-пути: /etc для поиска своих конфигов, /var — для сохранения временных данных, /usr/share для поиска данных и т.п., что неправильно. Правильный вариант кроме указания корректных опций конфигурирования потребует соответсвующего изменения Makefile'ов пакетов, что значительно более трудоёмкая задача. Первый путь был выбран исходя из перечисленных доводов? Не будет ли это нарушение FHS выглядеть коряво? Здесь лежат все необходимые правки билдрута, если будет выбран «правильный» путь. С пакетами, повторюсь, придётся повозиться отдельно.

Совершенно верно, те же uclibc обновить или base-files к примеру...Тогда наиболее логичный путь — это установка первым делом полноценного opkg. И не надо будет обременять "эмулятор" opkg всеми функциями настоящего (в части, записью статусов распакованных пакетов в /opt/lib/opkg/status), и будет возможность обновлять в т.ч. базовые файлы и uclibc-библиотеки.

В смысле? Т.е. при выполнении opkg upgrade должны обновляться в т.ч. те пакеты, которые были распакованы из /opt/install?Про Entware пока речь не заходила, но там не в пакетах только сам статический бинарник opkg. Это сделано умышлено, для того, чтобы он остался работоспособен даже в том случае, если остальная система в руинах. Кстати, сто́ит ли мне сделать такой html-индекс для keenopt для облегчения навигации по пакетам? Чуть позже сделаю на своих мощностях, посмотрим насколько будет полезен.

Примеры из моих пакетов: раз, два, три. Раз у /opt/install цель — установить окружение для работы, то теоретически может понадобиться и /opt/bin/sh. Это можно учесть в зависимостях пакета, если, конечно, при установке из /opt/install эти зависимости будут учитываться. Если зависимости не будут учитываться, что хорошо бы распаковывать пакеты из /opt/install в алфавитном порядке, тогда зависимости можно будет соблюсти, назвав пакеты 00utility1.ipk, 02utility1.ipk и т.д.

Пока просто вожу руками в воздухе. Если удастся получить девайс на тест, то внесу посильный вклад. Первая засада с выполнением post/pre-inst скриптов видится в том, что они представляют собой shell-скрипты, начинающиеся shebang'ом #!/bin/sh и к моменту их выполнения /opt/bin/sh ещё может не существовать.

Правильно ли я понимаю то, что пакеты, положенные в папку /opt/install будут распаковываться при каждой загрузке роутера, причём post/pre-inst скрипты в пакетах выполняться не будут?

Скорее всего, в .config билдрута указана CONFIG_SOFT_FLOAT, а тулчейн собран с hardfloat.